[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1323870059.23971.23.camel@gandalf.stny.rr.com>
Date: Wed, 14 Dec 2011 08:40:59 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
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
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?
> 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.
-- Steve
--
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