[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFw8cAeixca_LWJN7C5W52i7uC-WN-CdND37hvCYHVdRVw@mail.gmail.com>
Date: Tue, 29 Nov 2011 13:05:15 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andi Kleen <andi@...stfloor.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Paul Turner <pjt@...gle.com>
Subject: Re: Perhaps a side effect regarding NMI returns
On Tue, Nov 29, 2011 at 12:58 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Note, the reason that I've been looking at this code, is because I'm
> looking at implementing your idea to handle irets in NMIs, caused by
> faults, exceptions, and the reason I really care about: debugging.
>
> Your proposal is here:
>
> https://lkml.org/lkml/2010/7/14/264
Ahh, good that you pointed to it, I'd completely forgotten about this one.
Yeah. Simplifying NMI and not mixing up the paranoid stuff sounds like
a good idea, and then if we do the nice NMI counting thing and avoid
the whole problem with NMI and iret, that would be a nice cleanup in
itself.
So if that patch I posted works for you (with some NMI-heavy workload
like non-PEBS tracing) I think it's the way to go.
Too late for 3.2 obviously, since I don't think anybody has actually
reported the "delayed NMI's" as a real problem - so even if it's a
bug, it's not a bug we should try to fix at this stage.
Linus
--
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