linux-kernel - [PATCH] doc: memory-barriers.txt: Minor correction in 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 for Android: free password hash cracker in your pocket

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

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/