powerpc: Fix atomic_xxx_return barrier semantics
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tue, 15 Nov 2011 17:11:27 +0000 (17:11 +0000)
committerBenjamin Herrenschmidt <benh@kernel.crashing.org>
Thu, 17 Nov 2011 05:26:07 +0000 (16:26 +1100)
commitb97021f85517552ea8a0d2c1680c1ee4beab6d14
treef8f4c0af8d7a76d405fcae62f2ddecff642cc4e9
parenta9a8f77ac72d6dd3c92ea268291678836f77681c
powerpc: Fix atomic_xxx_return barrier semantics

The Documentation/memory-barriers.txt document requires that atomic
operations that return a value act as a memory barrier both before
and after the actual atomic operation.

Our current implementation doesn't guarantee this. More specifically,
while a load following the isync can not be issued before stwcx. has
completed, that completion doesn't architecturally means that the
result of stwcx. is visible to other processors (or any previous stores
for that matter) (typically, the other processors L1 caches can still
hold the old value).

This has caused an actual crash in RCU torture testing on Power 7

This fixes it by changing those atomic ops to use new macros instead
of RELEASE/ACQUIRE barriers, called ATOMIC_ENTRY and ATMOIC_EXIT barriers,
which are then defined respectively to lwsync and sync.

I haven't had a chance to measure the performance impact (or rather
what I measured with kernel compiles is in the noise, I yet have to
find a more precise benchmark)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
arch/powerpc/include/asm/atomic.h
arch/powerpc/include/asm/bitops.h
arch/powerpc/include/asm/futex.h
arch/powerpc/include/asm/synch.h