Skip to content

Commit

Permalink
documentation: Subsequent writes ordered by rcu_dereference()
Browse files Browse the repository at this point in the history
The current memory-barriers.txt does not address the possibility of
a write to a dereferenced pointer.  This should be rare, but when it
happens, we need that write -not- to be clobbered by the initialization.
This commit therefore adds an example showing a data dependency ordering
a later data-dependent write.

Reported-by: Leonid Yegoshin <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
  • Loading branch information
paulmck committed Mar 14, 2016
1 parent 0e4bd2a commit 92a84dd
Showing 1 changed file with 24 additions and 0 deletions.
24 changes: 24 additions & 0 deletions Documentation/memory-barriers.txt
Original file line number Diff line number Diff line change
Expand Up @@ -555,6 +555,30 @@ between the address load and the data load:
This enforces the occurrence of one of the two implications, and prevents the
third possibility from arising.

A data-dependency barrier must also order against dependent writes:

CPU 1 CPU 2
=============== ===============
{ A == 1, B == 2, C = 3, P == &A, Q == &C }
B = 4;
<write barrier>
WRITE_ONCE(P, &B);
Q = READ_ONCE(P);
<data dependency barrier>
*Q = 5;

The data-dependency barrier must order the read into Q with the store
into *Q. This prohibits this outcome:

(Q == B) && (B == 4)

Please note that this pattern should be rare. After all, the whole point
of dependency ordering is to -prevent- writes to the data structure, along
with the expensive cache misses associated with those writes. This pattern
can be used to record rare error conditions and the like, and the ordering
prevents such records from being lost.


[!] Note that this extremely counterintuitive situation arises most easily on
machines with split caches, so that, for example, one cache bank processes
even-numbered cache lines and the other bank processes odd-numbered cache
Expand Down

0 comments on commit 92a84dd

Please sign in to comment.