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 exce
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 T
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
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
> > > to
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 b
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() che
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 can
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
searchi
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 tha
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 co
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 nes
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 re-en
* 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 th
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() WARN_ON_ONCE
18 matches
Mail list logo
