summaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>2011-11-15 21:11:27 +0400
committerBenjamin Herrenschmidt <benh@kernel.crashing.org>2011-11-17 09:26:07 +0400
commitb97021f85517552ea8a0d2c1680c1ee4beab6d14 (patch)
treef8f4c0af8d7a76d405fcae62f2ddecff642cc4e9 /COPYING
parenta9a8f77ac72d6dd3c92ea268291678836f77681c (diff)
downloadlinux-b97021f85517552ea8a0d2c1680c1ee4beab6d14.tar.xz
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>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions