sparc64 cmpxchg is not a full memory barrier anymore ?

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

Hi David,

I took a look at the current sparc64 cmpxchg implementation in the Linux
kernel and stumbled on this commit:

commit 293666b7a17cb7a389fc274980439212386a19c4
Author: David S. Miller <davem@davemloft.net>
Date:   Sat Nov 15 13:33:25 2008 -0800

    sparc64: Stop using memory barriers for atomics and locks.
    
    The kernel always executes in the TSO memory model now,
    so none of this stuff is necessary any more.
    
    With helpful feedback from Nick Piggin.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

Reading p. 152 A.9 Compare and Swap, I see that the cas instruction does
not imply a memory barrier.

Reading http://docs.sun.com/app/docs/doc/801-6678/6i11oelck?a=view

I see that:

"TSO guarantees that the store, FLUSH, and atomic load-store
instructions of all processors appear to be executed by memory serially
in a single order called the memory order. Furthermore, the sequence of
store, FLUSH, and atomic load-store instructions in the memory order for
a given processor is identical to the sequence in which they were issued
by the processor."

So it provides no guarantee whatsoever wrt loads. However, reading
Documentation/memory-barriers.txt:

"Whilst they are technically interprocessor interaction considerations,
atomic operations are noted specially as some of them imply full memory
barriers and some don't, but they're very heavily relied on as a group
throughout the kernel." -> cmpxchg is part of them.

The same applies to the other atomic instructions we find in this list.
How is the correct ordering of loads wrt to cmxchg (and other atomic
ops) still ensured by this modification?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68