Messages in this thread | | | Date | Thu, 29 Sep 2016 09:43:53 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability |
| |
On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote: > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote: > > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote: > > > 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 <stern@rowland.harvard.edu> > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > > > + 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. > > > > This is the powerpc lwsync quirk, right? Where the barrier disappears > > when it looses the store. > > > > Or is there more to it? Its not entirely clear from the Changelog, which > > I feel should describe the reason for the behaviour. > > If I've groked it correctly, it's for cases like: > > > PO: > Wx=1 > WyRel=1 > > P1: > Wy=2 > > P2: > RyAcq=2 > Rx=0 > > Final value of y is 2. > > > This is permitted on arm64. If you make P1's store a store-release, then > it's forbidden, but I suspect that's not generally true of the kernel > memory model.
That is the one! And to Peter's point, powerpc does the same for the example as shown. However, on powerpc, upgrading P1's store to release has no effect because there is no earlier access for the resulting lwsync to influence. For whatever it might be worth, C11 won't guarantee ordering in that case, either. Nor will the current Linux-kernel memory model. (Yes, I did just try it to make sure. Why do you ask?)
So you guys are fishing for an expanded commit log, for example, like the following? ;-)
Thanx, Paul
------------------------------------------------------------------------
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, for example:
P0(int *x, int *y) { WRITE_ONCE(*x, 1); smp_wmb(); smp_store_release(y, 1); }
P1(int *y) { smp_store_release(y, 2); }
P2(int *x, int *y) { r1 = smp_load_acquire(y); r2 = READ_ONCE(*x); }
Both ARM and powerpc allow the "after the dust settles" outcome (r1=2 && r2=0), as does the current version of the early prototype Linux-kernel memory model.
This commit therefore updates the documentation to call this vulnerability out explicitly.
| |