Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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

Documentation/memory-barriers.txt

+6 −3
Original line number Original line Diff line number Diff line
@@ -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. */