[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160901111915.GB6721@arm.com>
Date: Thu, 1 Sep 2016 12:19:15 +0100
From: Will Deacon <will.deacon@....com>
To: Manfred Spraul <manfred@...orfullife.com>
Cc: Peter Zijlstra <peterz@...radead.org>, benh@...nel.crashing.org,
paulmck@...ux.vnet.ibm.com, Ingo Molnar <mingo@...e.hu>,
Boqun Feng <boqun.feng@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, 1vier1@....de,
Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [PATCH 1/4] spinlock: Document memory barrier rules
On Thu, Sep 01, 2016 at 01:04:26PM +0200, Manfred Spraul wrote:
> If I understand it right, the rules are:
> 1. spin_unlock_wait() must behave like spin_lock();spin_unlock();
> 2. spin_is_locked() must behave like spin_trylock() ? spin_unlock(),TRUE :
> FALSE
I don't think spin_is_locked is as strong as all that. On arm64 and ppc,
it's just smp_mb(); followed by a check on the lock value. It can't be
used for the same sorts of inter-CPU synchronisation that spin_unlock_wait
provides.
> 3. the ACQUIRE during spin_lock applies to the lock load, not to the store.
Correct. This is already documented for things like cmpxchg.
> sem.c and nf_conntrack.c need only rule 1 now, but I would document the rest
> as well, ok?
>
> I'll update the patches.
Please CC me!
Will
Powered by blists - more mailing lists