Re: NMI handling rework for x86

[John Levon]

On Fri, Nov 15, 2002 at 03:18:22AM -0500, Zwane Mwaikambo wrote:

> > Once you remove a handler from the list, any subsequent NMI is *not*
> > going to see the handler. So even if another CPU is executing the same
> > handler, if you wait for the RCU callback, you can guarantee that
> > no-one is executing the deleted handler. RCU will wait for all the
> > CPUs to context switch or execute user-level code atleast once.
> 
> I think you're confusing NMI handling, they aren't like your normal 
> interrupts. You're not going to see that context switch.

The dangerous part is when a particular NMI interrupt is holding a
reference to the removed item on the list. Now, after *every* CPU has
been through a normal schedule, none of them can still be running /that
particular/ NMI interrupt: the fact they can be running other NMIs
constantly is neither here nor there, as newly generated NMIs can't see
the deleted element anyway.

> > Corey's code doesn't rely on completion() to ensure this, it relies
> > on RCU to make sure that nobody is running the handler. The key is
> > that once the pointers between the prev and the next of the deleted
> 
> Can you change prev and next atomically?

As long as they're naturally aligned.

> > NMI handler are set, subsequent NMIs aren't going to see that handler.
> > context switch/user-level means that CPU must have exited any
> > NMI handler it may have been executing at the time of deletion.
> 
> Again, are you mistaking this for a normal interrupt?

Zwane you're going to have describe a race if you think you can see one
- neither I nor Dipankar follow your point

> At a fair interrupt rate i'd rather have that fill my caches, less time 
> spent in the NMI handler means more overall system time.

-EPARSE. You will spend more time in the NMI handlers bouncing the line
across. 

regards
john
-- 
Khendon's Law: If the same point is made twice by the same person,
the thread is over.