Messages in this thread | | | Date | Tue, 7 Jun 2016 14:00:16 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() |
| |
On Tue, Jun 07, 2016 at 07:43:15PM +0800, Boqun Feng wrote: > On Mon, Jun 06, 2016 at 06:08:36PM +0200, Peter Zijlstra wrote: > > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c > > index ce2f75e32ae1..e1c29d352e0e 100644 > > --- a/kernel/locking/qspinlock.c > > +++ b/kernel/locking/qspinlock.c > > @@ -395,6 +395,8 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > > * pending stuff. > > * > > * p,*,* -> n,*,* > > + * > > + * RELEASE, such that the stores to @node must be complete. > > */ > > old = xchg_tail(lock, tail); > > next = NULL; > > @@ -405,6 +407,15 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > > */ > > if (old & _Q_TAIL_MASK) { > > prev = decode_tail(old); > > + /* > > + * The above xchg_tail() is also load of @lock which generates, > > + * through decode_tail(), a pointer. > > + * > > + * The address dependency matches the RELEASE of xchg_tail() > > + * such that the access to @prev must happen after. > > + */ > > + smp_read_barrier_depends(); > > Should this barrier be put before decode_tail()? Because it's the > dependency old -> prev that we want to protect here.
I don't think it matters one way or the other. The old->prev transformation is pure; it doesn't depend on any state other than old.
I put it between prev and dereferences of prev, because that's what made most sense to me; but really anywhere between the load of @old and the first dereference of @prev is fine I suspect.
| |