Commit a5052657 authored Apr 12, 2016 by Paul E. McKenney Committed by Ingo Molnar Apr 13, 2016

locking/Documentation: Clarify relationship of barrier() to control dependencies



The current documentation claims that the compiler ignores barrier(),
which is not the case.  Instead, the compiler carefully pays attention
to barrier(), but in a creative way that still manages to destroy
the control dependency.  This commit sets the story straight.

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bobby.prani@gmail.com
Cc: dhowells@redhat.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com


Signed-off-by: Ingo Molnar <mingo@kernel.org>

parent 5c8a010c

Documentation/memory-barriers.txt

+4 −3

Original line number	Diff line number	Diff line
		@@ -813,9 +813,10 @@ In summary:
		the same variable, then those stores must be ordered, either by
		preceding both of them with smp_mb() or by using smp_store_release()
		to carry out the stores. Please note that it is -not- sufficient
		to use barrier() at beginning of each leg of the "if" statement,
		as optimizing compilers do not necessarily respect barrier()
		in this case.
		to use barrier() at beginning of each leg of the "if" statement
		because, as shown by the example above, optimizing compilers can
		destroy the control dependency while respecting the letter of the
		barrier() law.

		(*) Control dependencies require at least one run-time conditional
		between the prior load and the subsequent store, and this