On Wed, Oct 16, 2013 at 03:57:30PM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2013 12:36:32 -0700
> "Paul E. McKenney" wrote:
>
>
> > > Ah but we have an in_interrupt() check in context_tracking_user_enter()
> > > that protects
> > > us against that.
> >
> > Here you are relying on the
On Wed, Oct 16, 2013 at 03:57:30PM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 12:36:32 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Ah but we have an in_interrupt() check in context_tracking_user_enter()
that protects
us against that.
Here you are relying on
On Wed, Oct 16, 2013 at 12:36:32PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 16, 2013 at 03:08:57PM +0200, Frederic Weisbecker wrote:
> > On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
> > > On Wed, 16 Oct 2013 13:40:37 +0200
> > > Frederic Weisbecker wrote:
> > >
> > > > On
On Wed, Oct 16, 2013 at 12:36:32PM -0700, Paul E. McKenney wrote:
On Wed, Oct 16, 2013 at 03:08:57PM +0200, Frederic Weisbecker wrote:
On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 13:40:37 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
x.vnet.ibm.com; Peter Zijlstra; x...@kernel.org; Wang,
> Xiaoming; Li, Zhuangzhi; Liu, Chuansheng
> Subject: Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
>
>
> * Steven Rostedt wrote:
>
> > On Wed, 16 Oct 2013 08:11:18 +0200
> > Ingo Mol
On Wed, 16 Oct 2013 12:36:32 -0700
"Paul E. McKenney" wrote:
> > Ah but we have an in_interrupt() check in context_tracking_user_enter()
> > that protects
> > us against that.
>
> Here you are relying on the exception being treated as an interrupt,
> correct?
I don't think so. It's relying
On Wed, Oct 16, 2013 at 09:37:12AM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2013 15:28:15 +0200
> Frederic Weisbecker wrote:
>
> > On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
> > > On Wed, 16 Oct 2013 15:08:57 +0200
> > > Frederic Weisbecker wrote:
> > >
> > >
> > > >
On Wed, Oct 16, 2013 at 03:08:57PM +0200, Frederic Weisbecker wrote:
> On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
> > On Wed, 16 Oct 2013 13:40:37 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
> > > > Since the
On Wed, 16 Oct 2013 15:28:15 +0200
Frederic Weisbecker wrote:
> On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
> > On Wed, 16 Oct 2013 15:08:57 +0200
> > Frederic Weisbecker wrote:
> >
> >
> > > Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed
> > >
On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2013 15:08:57 +0200
> Frederic Weisbecker wrote:
>
>
> > Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed to
> > happen
> > between rcu_nmi_enter() and rcu_nmi_exit(). rdtp->dynticks would
On Wed, 16 Oct 2013 15:08:57 +0200
Frederic Weisbecker wrote:
> Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed to
> happen
> between rcu_nmi_enter() and rcu_nmi_exit(). rdtp->dynticks would be
> incremented in the
> wrong way.
>
> Ah but we have an in_interrupt()
On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2013 13:40:37 +0200
> Frederic Weisbecker wrote:
>
> > On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
> > > Since the NMI iretq nesting has been fixed, there's no reason that
> > > an NMI handler
On Wed, 16 Oct 2013 14:51:11 +0200
Ingo Molnar wrote:
> So kallsyms_lookup() faulted, while the NMI watchdog triggered a
> show_regs()? How is that possible?
It was a vmalloc fault. Do modules keep their symbol tables in a
vmalloced area? If so, I think the get_ksymbol() can fault when
On Wed, Oct 16, 2013 at 02:51:11PM +0200, Ingo Molnar wrote:
> The one posted in the thread shows:
>
> [ 17.148755] [] do_page_fault+0x8/0x10
> [ 17.153926] [] error_code+0x5a/0x60
> [ 17.158905] [] ? __do_page_fault+0x4a0/0x4a0
> [ 17.164760] [] ? module_address_lookup+0x29/0xb0
> [
* Steven Rostedt wrote:
> On Wed, 16 Oct 2013 08:11:18 +0200
> Ingo Molnar wrote:
>
> >
> > * Steven Rostedt wrote:
> >
> > > Since the NMI iretq nesting has been fixed, there's no reason that
> > > an NMI handler can not take a page fault for vmalloc'd code. No locks
> > > are taken in
On Wed, 16 Oct 2013 13:40:37 +0200
Frederic Weisbecker wrote:
> On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
> > Since the NMI iretq nesting has been fixed, there's no reason that
> > an NMI handler can not take a page fault for vmalloc'd code. No locks
> > are taken in that
On Wed, 16 Oct 2013 08:11:18 +0200
Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
> > Since the NMI iretq nesting has been fixed, there's no reason that
> > an NMI handler can not take a page fault for vmalloc'd code. No locks
> > are taken in that code path, and the software now handles
On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
> Since the NMI iretq nesting has been fixed, there's no reason that
> an NMI handler can not take a page fault for vmalloc'd code. No locks
> are taken in that code path, and the software now handles nested NMIs
> when the fault
* Steven Rostedt wrote:
> Since the NMI iretq nesting has been fixed, there's no reason that
> an NMI handler can not take a page fault for vmalloc'd code. No locks
> are taken in that code path, and the software now handles nested NMIs
> when the fault re-enables NMIs on iretq.
>
> Not only
* Steven Rostedt rost...@goodmis.org wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are taken in that code path, and the software now handles nested NMIs
when the fault re-enables NMIs on iretq.
On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are taken in that code path, and the software now handles nested NMIs
when the fault
On Wed, 16 Oct 2013 08:11:18 +0200
Ingo Molnar mi...@kernel.org wrote:
* Steven Rostedt rost...@goodmis.org wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are taken in that code path, and
On Wed, 16 Oct 2013 13:40:37 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are
* Steven Rostedt rost...@goodmis.org wrote:
On Wed, 16 Oct 2013 08:11:18 +0200
Ingo Molnar mi...@kernel.org wrote:
* Steven Rostedt rost...@goodmis.org wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for
On Wed, Oct 16, 2013 at 02:51:11PM +0200, Ingo Molnar wrote:
The one posted in the thread shows:
[ 17.148755] [c2825b08] do_page_fault+0x8/0x10
[ 17.153926] [c2823066] error_code+0x5a/0x60
[ 17.158905] [c2825b00] ? __do_page_fault+0x4a0/0x4a0
[ 17.164760] [c208d1a9] ?
On Wed, 16 Oct 2013 14:51:11 +0200
Ingo Molnar mi...@kernel.org wrote:
So kallsyms_lookup() faulted, while the NMI watchdog triggered a
show_regs()? How is that possible?
It was a vmalloc fault. Do modules keep their symbol tables in a
vmalloced area? If so, I think the get_ksymbol() can
On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 13:40:37 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI
On Wed, 16 Oct 2013 15:08:57 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed to
happen
between rcu_nmi_enter() and rcu_nmi_exit(). rdtp-dynticks would be
incremented in the
wrong way.
Ah but we have an
On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 15:08:57 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed to
happen
between rcu_nmi_enter() and rcu_nmi_exit(). rdtp-dynticks
On Wed, 16 Oct 2013 15:28:15 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 15:08:57 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Faults can call rcu_user_exit() / rcu_user_enter(). This
On Wed, Oct 16, 2013 at 03:08:57PM +0200, Frederic Weisbecker wrote:
On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 13:40:37 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote:
Since
On Wed, Oct 16, 2013 at 09:37:12AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 15:28:15 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Wed, Oct 16, 2013 at 09:14:37AM -0400, Steven Rostedt wrote:
On Wed, 16 Oct 2013 15:08:57 +0200
Frederic Weisbecker fweis...@gmail.com
On Wed, 16 Oct 2013 12:36:32 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Ah but we have an in_interrupt() check in context_tracking_user_enter()
that protects
us against that.
Here you are relying on the exception being treated as an interrupt,
correct?
I don't think so.
; x...@kernel.org; Wang,
Xiaoming; Li, Zhuangzhi; Liu, Chuansheng
Subject: Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
* Steven Rostedt rost...@goodmis.org wrote:
On Wed, 16 Oct 2013 08:11:18 +0200
Ingo Molnar mi...@kernel.org wrote:
* Steven Rostedt rost
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are taken in that code path, and the software now handles nested NMIs
when the fault re-enables NMIs on iretq.
Not only that, if the vmalloc_fault()
Since the NMI iretq nesting has been fixed, there's no reason that
an NMI handler can not take a page fault for vmalloc'd code. No locks
are taken in that code path, and the software now handles nested NMIs
when the fault re-enables NMIs on iretq.
Not only that, if the vmalloc_fault()
36 matches
Mail list logo
