[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160607114315.GF23133@insomnia>
Date: Tue, 7 Jun 2016 19:43:15 +0800
From: Boqun Feng <boqun.feng@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Will Deacon <will.deacon@....com>, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, manfred@...orfullife.com,
dave@...olabs.net, paulmck@...ux.vnet.ibm.com, Waiman.Long@....com,
tj@...nel.org, pablo@...filter.org, kaber@...sh.net,
davem@...emloft.net, oleg@...hat.com,
netfilter-devel@...r.kernel.org, sasha.levin@...cle.com,
hofrat@...dl.org, jejb@...isc-linux.org, chris@...kel.net,
rth@...ddle.net, dhowells@...hat.com, schwidefsky@...ibm.com,
mpe@...erman.id.au, ralf@...ux-mips.org, linux@...linux.org.uk,
rkuo@...eaurora.org, vgupta@...opsys.com, james.hogan@...tec.com,
realmz6@...il.com, ysato@...rs.sourceforge.jp, tony.luck@...el.com,
cmetcalf@...lanox.com
Subject: Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()
On Mon, Jun 06, 2016 at 06:08:36PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 02, 2016 at 06:57:00PM +0100, Will Deacon wrote:
> > > This 'replaces' commit:
> > >
> > > 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()")
> > >
> > > and seems to still work with the test case from that thread while
> > > getting rid of the extra barriers.
>
> New version :-)
>
> This one has moar comments; and also tries to address an issue with
> xchg_tail(), which is its own consumer. Paul, Will said you'd love the
> address dependency through union members :-)
>
> (I should split this in at least 3 patches I suppose)
>
> ARM64 and PPC should provide private versions of is_locked and
> unlock_wait; because while this one deals with the unordered store as
> per qspinlock construction, it still relies on cmpxchg_acquire()'s store
> being visible.
>
[snip]
> 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.
Regards,
Boqun
> +
> WRITE_ONCE(prev->next, node);
>
> pv_wait_node(node, prev);
[snip]
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists