lkml.org 
[lkml]   [2016]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2016-06-07 14:21    [W:1.265 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site