linux-kernel - [tip:locking/core] locking/Documentation: Clarify relationship of barrier() to control dependencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Apr 2016 00:27:49 -0700
From:	"tip-bot for Paul E. McKenney" <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	akpm@...ux-foundation.org, hpa@...or.com,
	paulmck@...ux.vnet.ibm.com, mingo@...nel.org,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	mathieu.desnoyers@...icios.com, tglx@...utronix.de,
	torvalds@...ux-foundation.org
Subject: [tip:locking/core] locking/Documentation: Clarify relationship of
 barrier() to control dependencies

Commit-ID:  a5052657c164107032d521f0d9e92703d78845f2
Gitweb:     http://git.kernel.org/tip/a5052657c164107032d521f0d9e92703d78845f2
Author:     Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
AuthorDate: Tue, 12 Apr 2016 08:52:49 -0700
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Wed, 13 Apr 2016 08:52:21 +0200

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@...icios.com>
Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: bobby.prani@...il.com
Cc: dhowells@...hat.com
Cc: dipankar@...ibm.com
Cc: dvhart@...ux.intel.com
Cc: edumazet@...gle.com
Cc: fweisbec@...il.com
Cc: jiangshanlai@...il.com
Cc: josh@...htriplett.org
Cc: oleg@...hat.com
Cc: rostedt@...dmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 Documentation/memory-barriers.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 3729cbe..ec12890 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -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