redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

doc: Call out smp_mb__after_unlock_lock() transitivity 

Although "full barrier" should be interpreted as providing transitivity,
it is worth eliminating any possible confusion.  This commit therefore
adds "(including transitivity)" to eliminate any possible confusion.

Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
steinar/wifi_calib_4_9_kernel
Paul E. McKenney 2015-07-13 15:55:52 -07:00
parent 9af194cefc
commit 96d7744e0a
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/memory-barriers.txt
View File

@ -1858,11 +1858,12 @@ Similarly, the reverse case of a RELEASE followed by an ACQUIRE does not
imply a full memory barrier. If it is necessary for a RELEASE-ACQUIRE
pair to produce a full barrier, the ACQUIRE can be followed by an
smp_mb__after_unlock_lock() invocation. This will produce a full barrier
if either (a) the RELEASE and the ACQUIRE are executed by the same
CPU or task, or (b) the RELEASE and ACQUIRE act on the same variable.
The smp_mb__after_unlock_lock() primitive is free on many architectures.
Without smp_mb__after_unlock_lock(), the CPU's execution of the critical
sections corresponding to the RELEASE and the ACQUIRE can cross, so that:
(including transitivity) if either (a) the RELEASE and the ACQUIRE are
executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on
the same variable. The smp_mb__after_unlock_lock() primitive is free
on many architectures. Without smp_mb__after_unlock_lock(), the CPU's
execution of the critical sections corresponding to the RELEASE and the
ACQUIRE can cross, so that:
*A = a;
RELEASE M