Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1416129
| From | Boqun Feng <boqun.feng@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() |
| Date | 2016-06-07 14:50 +0200 |
| Message-ID | <rHoCd-2KD-3@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <rFDP3-8ex-9@gated-at.bofh.it> <rFF4t-HB-13@gated-at.bofh.it> <rH5gd-7ea-13@gated-at.bofh.it> <rHnGa-2aD-23@gated-at.bofh.it> <rHnZw-2wN-31@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Tue, Jun 07, 2016 at 02:00:16PM +0200, Peter Zijlstra wrote:
> 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.
>
But wouldn't the old -> prev transformation get broken on Alpha
semantically in theory? Because Alpha could reorder the LOAD part of the
xchg_tail() and decode_tail(), which results in prev points to other
cpu's mcs_node.
Though, this is fine in current code, because xchg_release() is actually
xchg() on Alpha, and Alpha doesn't use qspinlock.
> 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.
I understand the barrier here serves more for a documentation purpose,
and I don't want to a paranoid ;-) I'm fine with the current place, just
thought we could put it at somewhere more conforming to our memory
model.
/me feel myself a paranoid anyway...
Regards,
Boqun
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-02 14:00 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Boqun Feng <boqun.feng@gmail.com> - 2016-06-02 16:30 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-02 16:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Boqun Feng <boqun.feng@gmail.com> - 2016-06-02 17:10 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Boqun Feng <boqun.feng@gmail.com> - 2016-06-02 18:00 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-02 18:10 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-02 18:40 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Will Deacon <will.deacon@arm.com> - 2016-06-02 20:00 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-03 00:00 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Will Deacon <will.deacon@arm.com> - 2016-06-03 14:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-03 15:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Will Deacon <will.deacon@arm.com> - 2016-06-03 19:40 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-03 21:20 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-03 15:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-06 18:10 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Boqun Feng <boqun.feng@gmail.com> - 2016-06-07 13:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-07 14:10 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Boqun Feng <boqun.feng@gmail.com> - 2016-06-07 14:50 +0200
Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-06-07 19:40 +0200
csiph-web