On Mon, Sep 05, 2016 at 03:37:14AM -0700, Paul E. McKenney wrote: > On Mon, Sep 05, 2016 at 11:37:53AM +0200, Peter Zijlstra wrote: > > Hi all, > > > > So recently I've had two separate issues that touched upon > > smp_mb__before_spinlock(). > > > > > > Since its inception, our understanding of ACQUIRE, esp. as applied to > > spinlocks, has changed somewhat. Also, I wonder if, with a simple > > change, we cannot make it provide more. > > > > The problem with the comment is that the STORE done by spin_lock isn't > > itself ordered by the ACQUIRE, and therefore a later LOAD can pass over > > it and cross with any prior STORE, rendering the default WMB > > insufficient (pointed out by Alan). > > > > Now, this is only really a problem on PowerPC and ARM64, the former of > > which already defined smp_mb__before_spinlock() as a smp_mb(), the > > latter does not, Will? > > > > The second issue I wondered about is spinlock transitivity. All except > > powerpc have RCsc locks, and since Power already does a full mb, would > > it not make sense to put it _after_ the spin_lock(), which would provide > > the same guarantee, but also upgrades the section to RCsc. > > > > That would make all schedule() calls fully transitive against one > > another. > > > > > > That is, would something like the below make sense? > > Looks to me like you have reinvented smp_mb__after_unlock_lock()...
Will said the same, but that one doesn't in fact do the first bit, as ARM64 also needs a full barrier for that, while it doesn't need that to upgrade to RCsc.