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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1407797503-24727-1-git-send-email-bobby.prani@gmail.com>
Date:	Mon, 11 Aug 2014 18:51:39 -0400
From:	Pranith Kumar <bobby.prani@...il.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Josh Triplett <josh@...htriplett.org>,
	David Howells <dhowells@...hat.com>,
	Masanari Iida <standby24x7@...il.com>,
	linux-kernel@...r.kernel.org (open list)
Subject: [PATCH] doc: memory-barriers.txt: Minor correction in Control dependencies

Minor corrections in memory-barriers.txt document.

Signed-off-by: Pranith Kumar <bobby.prani@...il.com>
---
 Documentation/memory-barriers.txt | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index abec3f9..41a6c9c 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -627,7 +627,7 @@ proving the value of 'a', and the pair of barrier() invocations are
 required to prevent the compiler from pulling the two identical stores
 to 'b' out from the legs of the "if" statement.
 
-It is important to note that control dependencies absolutely require a
+It is important to note that control dependencies absolutely require
 a conditional.  For example, the following "optimized" version of
 the above example breaks ordering, which is why the barrier() invocations
 are absolutely required if you have identical stores in both legs of
@@ -652,7 +652,7 @@ for example, as follows:
 		do_something();
 	} else {
 		barrier();
-		ACCESS_ONCE(b) = q / 3;
+		ACCESS_ONCE(b) = q / 2;
 		do_something_else();
 	}
 
@@ -710,7 +710,7 @@ x and y both being zero:
 
 The above two-CPU example will never trigger the assert().  However,
 if control dependencies guaranteed transitivity (which they do not),
-then adding the following two CPUs would guarantee a related assertion:
+then adding the following CPU would guarantee a related assertion:
 
 	CPU 2
 	=====================
@@ -719,8 +719,8 @@ then adding the following two CPUs would guarantee a related assertion:
 	assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */
 
 But because control dependencies do -not- provide transitivity, the
-above assertion can fail after the combined four-CPU example completes.
-If you need the four-CPU example to provide ordering, you will need
+above assertion can fail after the combined three-CPU example completes.
+If you need the three-CPU example to provide ordering, you will need
 smp_mb() between the loads and stores in the CPU 0 and CPU 1 code fragments,
 that is, just before or just after the "if" statements.
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ