Messages in this thread | | | Date | Wed, 10 Aug 2016 11:33:04 -0700 | From | "Paul E. McKenney" <> | Subject | Re: spin_lock implicit/explicit memory barrier |
| |
On Wed, Aug 10, 2016 at 10:05:37AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > > Hi Benjamin, Hi Michael, > > > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to > > arch_spin_is_locked()"): > > > > For the ipc/sem code, I would like to replace the spin_is_locked() with > > a smp_load_acquire(), see: > > > > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n367 > > > > http://www.ozlabs.org/~akpm/mmots/broken-out/ipc-semc-fix-complex_count-vs-simple-op-race.patch > > > > To my understanding, I must now add a smp_mb(), otherwise it would be > > broken on PowerPC: > > > > The approach that the memory barrier is added into spin_is_locked() > > doesn't work because the code doesn't use spin_is_locked(). > > > > Correct? > > Right, otherwise you aren't properly ordered. The current powerpc locks provide > good protection between what's inside vs. what's outside the lock but not vs. > the lock *value* itself, so if, like you do in the sem code, use the lock > value as something that is relevant in term of ordering, you probably need > an explicit full barrier. > > Adding Paul McKenney.
To amplify what Ben said...
Any CPU holding a given lock will see any previous accesses made under the protection of that lock.
A CPU -not- holding the lock can see misordering. As Ben noted, to that non-lock-holding CPU it might appear that a write made under the protection of that lock was made after the lock was released. Similarly, to that CPU it might appear that a load done under the protection of that lock completed before the lock was acquired. Finally, a CPU not holding the lock might see a store by one CPU holding the lock as happening after a load (from some other variable) by the next CPU holding that lock.
Thanx, Paul
| |