Re: [RFC,PATCH] RCU: clean up a few remaining synchronize_kernel() calls

[Zwane Mwaikambo <zwane@arm.linux.org.uk>]

Hello Paul,

On Sun, 26 Jun 2005, Paul E. McKenney wrote:

> How does the following look for NMI-RCU documentation?

That looks good, there is just one bit i'm not entirely sure about and i'd 
appreciate it if you could entertain me for a bit;

Answer to Quick Quiz

        Why might the rcu_dereference() be necessary on Alpha, given
        that the code reference by the pointer is read-only?

        Answer: The caller to set_nmi_callback() might well have
                initialized some data that is to be used by the
                new NMI handler.  In this case, the rcu_dereference()
                would be needed, because otherwise a CPU that received
                an NMI just after the new handler was set might see
                the pointer to the new NMI handler, but the old
                pre-initialized version of the handler's data.

Reading that i would think the general programming model for this would 
be;

setup data
write barrier
setup callback

Isn't that still required considering the following scenario;

CPU0			CPU1
setup data		<NMI>
setup callback		...
...			call callback

on i386, interrupts are data synchronising events, however if we happen to 
take an interrupt right when the data is being setup we won't synchronise 
with respect to that data. This could be achieved via the explicit write 
barrier after data setup or rcu_dereference in the NMI handler. Or perhaps 
i'm missing something?

Thanks!
	Zwane

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/