Re: NMI handling rework for x86

From: Zwane Mwaikambo (
Date: Fri Nov 15 2002 - 02:40:10 EST

On Fri, 15 Nov 2002, Dipankar Sarma wrote:

> The RCU part is fairly simple - you want to avoid having to acquire
> a lock for every NMI event to walk the handler so you do it
> lockfree. If a process running in a different CPU tries to
> free an nmi handler, it removes it from the list, issues an
> rcu callback (to be invoked after all CPUs have gone through
> a context switch or executed user-level code ensuring that the
> deleted nmi handler can't be running) and waits for completion of

How are you so sure the handler isn't running? You can get an NMI after
any cpu instruction inbetween all of that happening, not to mention that
it can happen on multiple processors means since its a shared nmi handler
list, you're almost never going to find that list not being traversed at
some stage by a processor. Try synchronising the cpus for a removal when
they're all handling an NMI every millisecond.

> the callback. The rcu callback handler wakes it up.
> It is all hidden under list_add_rcu()/list_del_rcu() and __list_for_each_rcu().

I don't think you can rely on completion() to ensure this. Its hardly an
atomic operation in this context, whats wrong with spin_trylock(nmi_handler_lock)
and do an early bailout on failure?



- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:36 EST