On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:

Paul E. McKenney wrote:

quoted

On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:

quoted

                               If you're depending on volatile writes 
being visible to other CPUs, you're screwed either way, because the CPU 
can hold that data in cache as long as it wants before it writes it to 
memory.  When this finally does happen, it will happen atomically, which 
is all that atomic_set guarantees.  If you need to guarantee that the 
value is written to memory at a particular time in your execution 
sequence, you either have to read it from memory to force the compiler to 
store it first (and a volatile cast in atomic_read will suffice for this) 
or you have to use LOCK_PREFIX instructions which will invalidate remote 
cache lines containing the same variable.  This patch doesn't change 
either of these cases.

The case that it -can- change is interactions with interrupt handlers.
And NMI/SMI handlers, for that matter.

You have a point here, but only if you can guarantee that the interrupt 
handler is running on a processor sharing the cache that has the 
not-yet-written volatile value.  That implies a strictly non-SMP 
architecture.  At the moment, none of those have volatile in their 
declaration of atomic_t, so this patch can't break any of them.

This can also happen when using per-CPU variables.  And there are a
number of per-CPU variables that are either atomic themselves or are
structures containing atomic fields.

							Thanx, Paul