Re: Perhaps a side effect regarding NMI returns

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2011-12-07 at 08:44 -0800, Linus Torvalds wrote:

> Sure. If it's tested, I have no problem with signing off on it, so
> just add it. Do you have some kind of commit message that makes sense
> and explains the NMI shadow issue?

How about something like this:

The NMI handler uses the paranoid_exit routine that checks the
NEED_RESCHED flag, and if it is set and the return is for userspace,
then interrupts are enabled, the stack is swapped to the thread's stack,
and schedule is called. The problem with this is that we are still in an
NMI context until an iret is executed. This means that any new NMIs are
now starved until an interrupt or exception occurs and does the iret.

As NMIs can not be masked and can interrupt any location, they are
treated as a special case. NEED_RESCHED should not be set in an NMI
handler. The interruption by the NMI should not disturb the work flow
for scheduling. Any IPI sent to a processor after sending the
NEED_RESCHED would have to wait for the NMI anyway, and after the IPI
finishes the schedule would be called as required.

There is no reason to do anything special leaving an NMI. Remove the
call to paranoid_exit and do a simple return. This not only fixes the
bug of starved NMIs, but it also cleans up the code.

-- Steve