Commit efdcd51a authored by Paul E. McKenney's avatar Paul E. McKenney

memory-barriers: Retain barrier() in fold-to-zero example

The transformation in the fold-to-zero example incorrectly omits the
barrier() directive.  This commit therefore adds it back in.
Reported-by: default avatarPranith Kumar <pranith@gatech.edu>
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parent 5646f7ac
...@@ -679,12 +679,15 @@ equal to zero, in which case the compiler is within its rights to ...@@ -679,12 +679,15 @@ equal to zero, in which case the compiler is within its rights to
transform the above code into the following: transform the above code into the following:
q = ACCESS_ONCE(a); q = ACCESS_ONCE(a);
barrier();
ACCESS_ONCE(b) = p; ACCESS_ONCE(b) = p;
do_something_else(); do_something_else();
This transformation loses the ordering between the load from variable 'a' This transformation fails to require that the CPU respect the ordering
and the store to variable 'b'. If you are relying on this ordering, you between the load from variable 'a' and the store to variable 'b'.
should do something like the following: Yes, the barrier() is still there, but it affects only the compiler,
not the CPU. Therefore, if you are relying on this ordering, you should
do something like the following:
q = ACCESS_ONCE(a); q = ACCESS_ONCE(a);
BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */ BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment