If two processes are related by a RELEASE+ACQUIRE pair, ordering can be broken if a third process overwrites the value written by the RELEASE operation before the ACQUIRE operation has a chance of reading it. This commit therefore updates the documentation to call this vulnerability out explicitly.
Reported-by: Alan Stern <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> --- Documentation/memory-barriers.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index ba818ecce6f9..a57679ec9441 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -490,14 +490,18 @@ And a couple of implicit varieties: the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE pair is -not- guaranteed to act as a full memory barrier. However, after an ACQUIRE on a given variable, all memory accesses preceding any prior - RELEASE on that same variable are guaranteed to be visible. In other - words, within a given variable's critical section, all accesses of all - previous critical sections for that variable are guaranteed to have - completed. + RELEASE on that same variable in that same chain of RELEASE+ACQUIRE + pairs are guaranteed to be visible. In other words, within a given + variable's critical section, all accesses of all previous critical + sections for that variable are guaranteed to have completed. This means that ACQUIRE acts as a minimal "acquire" operation and RELEASE acts as a minimal "release" operation. + However, please note that a chain of RELEASE+ACQUIRE pairs may be + broken by a store by another thread that overwrites the RELEASE + operation's store before the ACQUIRE operation's read. + A subset of the atomic operations described in atomic_ops.txt have ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no barrier semantics) definitions. For compound atomics performing both a load and a -- 2.5.2
