[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111214134412.GC2882@Krystal>
Date: Wed, 14 Dec 2011 08:44:13 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Paul Turner <pjt@...gle.com>
Subject: Re: [RFC][PATCH 5/5 v2] x86: Allow NMIs to hit breakpoints in i386
* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Wed, 2011-12-14 at 08:30 -0500, Mathieu Desnoyers wrote:
>
> > Just to make sure I understand: if an NMI nests over do_nmi between
> > nmi_postprocess() and the following iret (in which case the CPU is in
> > state NMI_NOT_RUNNING), we will end up with two NMI handlers nested on
> > the stack, right ? Given that there is no upper-bound on the nesting
> > level of this situation (although nesting like this more than once is
> > extremely unlikely), is this side-effect something we should care about
> > in terms of stack space usage ?
>
> At that point, there's very little on the stack to begin with. Just the
> one irq frame, and saved regs, plus the stack frame of this function. If
> we are hitting that many NMIs to cause a stack overflow, then I believe
> there's more issues than the overflow itself. Say, a livelock of NMIs?
Yep, if it's small then it's fine I guess.
>
> > Also, is the stack dump OOPS handler
> > aware of this stack layout that was until now impossible ?
>
> Since NMIs on i386 doesn't change the stack when interrupting the
> kernel, the OOPs handler never was aware of the NMI stack layout.
Makes sense, sounds good,
Thanks!
Mathieu
>
> -- Steve
>
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists