[PATCH v5 tip/core/locking] Memory-barrier documentation updates +smp_mb__after_unlock_lock()
From: Paul E. McKenney
Date: Mon Dec 09 2013 - 20:27:58 EST
Hello!
This series applies some long-needed updates to memory-barriers.txt and
adds an smp_mb__after_unlock_lock():
1. Add ACCESS_ONCE() calls where needed to ensure their inclusion
in code copy-and-pasted from this file.
2. Add long atomic examples alongside the existing atomics.
3. Prohibit architectures supporting the Linux kernel from
speculating stores.
4. Document what ACCESS_ONCE() does along with a number of situations
requiring its use.
5. Downgrade UNLOCK+LOCK to no longer imply a full barrier, at least
in the absence of smp_mb__after_unlock_lock(). See the LKML thread
that includes http://www.spinics.net/lists/linux-mm/msg65653.html
for more information.
6. Added smp_mb__after_unlock_lock() for all architectures. Because
all architectures are presumably providing full-barrier semantics
for UNLOCK+LOCK, these are all no-ops. Some will change if
low-latency-handoff queued locks are accepted.
7. Applied smp_mb__after_unlock_lock() as needed in RCU.
Changes from v4:
o Added Josh Triplett's Reviewed-by for 1-4.
o Applied feedback from Ingo Molnar and Jonathan Corbet.
o Trimmed Cc lists as suggested by David Miller.
o Added smp_mb__after_unlock_lock() changes.
Changes from v3:
o Fix typos noted by Peter Zijlstra.
o Added the documentation about ACCESS_ONCE(), which expands on
http://thread.gmane.org/gmane.linux.kernel.mm/82891/focus=14696,
ably summarized by Jon Corbet at http://lwn.net/Articles/508991/.
Changes from v2:
o Update examples so that that load against which the subsequent
store is to be ordered is part of the "if" condition.
o Add an example showing how the compiler can remove "if"
conditions and how to prevent it from doing so.
o Add ACCESS_ONCE() to the compiler-barrier section.
o Add a sentence noting that transitivity requires smp_mb().
Changes from v1:
o Combined with Peter Zijlstra's speculative-store-prohibition patch.
o Added more pitfalls to avoid when prohibiting speculative
stores, along with how to avoid them.
o Applied Josh Triplett's review comments.
Thanx, Paul
------------------------------------------------------------------------
b/Documentation/memory-barriers.txt | 760 +++++++++++++++++++++++++++-------
b/arch/arm/include/asm/barrier.h | 2
b/arch/arm64/include/asm/barrier.h | 2
b/arch/ia64/include/asm/barrier.h | 2
b/arch/metag/include/asm/barrier.h | 2
b/arch/mips/include/asm/barrier.h | 2
b/arch/powerpc/include/asm/barrier.h | 2
b/arch/s390/include/asm/barrier.h | 2
b/arch/sparc/include/asm/barrier_64.h | 2
b/arch/x86/include/asm/barrier.h | 2
b/include/asm-generic/barrier.h | 2
b/kernel/rcu/tree.c | 18
b/kernel/rcu/tree_plugin.h | 13
13 files changed, 670 insertions(+), 141 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/