All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC PATCH] x86: Barf when faults happen in NMI
Date: Tue, 28 Sep 2010 16:02:11 +0200	[thread overview]
Message-ID: <20100928140158.GA5449@nowhere> (raw)
In-Reply-To: <20100928103618.GB8514@elte.hu>

On Tue, Sep 28, 2010 at 12:36:18PM +0200, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > In x86, faults exit by executing the iret instruction, which then 
> > reenables NMIs if we faulted in NMI context. Then if a fault happens 
> > in NMI, another NMI can nest after the fault exits.
> > 
> > But we don't yet support nested NMIs because we have only one NMI 
> > stack. To prevent that, trigger a bug when a fault happens in NMI 
> > context.
> > 
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: H. Peter Anvin <hpa@zytor.com>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > ---
> > 
> > I first thought about putting it in the vmalloc fault path only. But 
> > then I saw more occasions for the kernel to fault (kmemcheck or so), 
> > and so I thought it should be better put in the all in one path. But I 
> > suspect you won't like that conditional in the big x86 fault path.
> > 
> > 
> >  arch/x86/mm/fault.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index 4c4508e..80c997e 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -955,6 +955,8 @@ do_page_fault(struct pt_regs *regs, unsigned long error_code)
> >  	int write;
> >  	int fault;
> >  
> > +	BUG_ON(in_nmi());
> > +
> 
> Hm, this is a fastpath, so it would be nice to put this into the vmalloc 
> and kmemcheck paths (even though it's less clean that way).
> 
> Also, a WARN_ON_ONCE() would probably help more in getting bug reports 
> out of such systems, than a BUG_ON() crashed kernel.
> 
> Thanks,
> 
> 	Ingo


Ok, will resend then.

Thanks.


      reply	other threads:[~2010-09-28 14:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-27 19:30 [RFC PATCH] x86: Barf when faults happen in NMI Frederic Weisbecker
2010-09-27 21:14 ` Mathieu Desnoyers
2010-09-27 23:52   ` Frederic Weisbecker
2010-09-28 10:36 ` Ingo Molnar
2010-09-28 14:02   ` Frederic Weisbecker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100928140158.GA5449@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.