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]
Message-ID: <tip-a5052657c164107032d521f0d9e92703d78845f2@git.kernel.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ