From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Manfred Spraul <manfred@colorfullife.com>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davidlohr Bueso <davidlohr@hp.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Susi Sonnenschein <1vier1@web.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: spin_lock implicit/explicit memory barrier
Date: Wed, 10 Aug 2016 10:05:37 +1000 [thread overview]
Message-ID: <1470787537.3015.83.camel@kernel.crashing.org> (raw)
In-Reply-To: <abcae6c7-6269-94e0-3e66-b7d07fbe10dc@colorfullife.com>
On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote:
> Hi Benjamin, Hi Michael,
>
> regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to
> arch_spin_is_locked()"):
>
> For the ipc/sem code, I would like to replace the spin_is_locked() with
> a smp_load_acquire(), see:
>
> http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n367
>
> http://www.ozlabs.org/~akpm/mmots/broken-out/ipc-semc-fix-complex_count-vs-simple-op-race.patch
>
> To my understanding, I must now add a smp_mb(), otherwise it would be
> broken on PowerPC:
>
> The approach that the memory barrier is added into spin_is_locked()
> doesn't work because the code doesn't use spin_is_locked().
>
> Correct?
Right, otherwise you aren't properly ordered. The current powerpc locks provide
good protection between what's inside vs. what's outside the lock but not vs.
the lock *value* itself, so if, like you do in the sem code, use the lock
value as something that is relevant in term of ordering, you probably need
an explicit full barrier.
Adding Paul McKenney.
Cheers,
Ben.
next prev parent reply other threads:[~2016-08-10 0:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 18:52 spin_lock implicit/explicit memory barrier Manfred Spraul
2016-08-10 0:05 ` Benjamin Herrenschmidt [this message]
2016-08-10 18:21 ` Manfred Spraul
2016-08-10 19:17 ` Davidlohr Bueso
2016-08-10 21:00 ` Paul E. McKenney
2016-08-15 20:06 ` Manfred Spraul
2016-08-15 20:28 ` Paul E. McKenney
2016-08-12 2:47 ` Boqun Feng
2016-08-12 18:43 ` Manfred Spraul
2016-08-22 9:15 ` Boqun Feng
2016-08-10 20:52 ` Paul E. McKenney
2016-08-10 22:23 ` Davidlohr Bueso
2016-08-10 22:58 ` Paul E. McKenney
2016-08-10 23:29 ` Davidlohr Bueso
2016-08-11 8:11 ` Peter Zijlstra
2016-08-11 18:31 ` Davidlohr Bueso
2016-08-12 2:59 ` Boqun Feng
2016-08-19 14:01 ` Peter Zijlstra
2016-08-10 23:59 ` Benjamin Herrenschmidt
2016-08-10 18:33 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1470787537.3015.83.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=1vier1@web.de \
--cc=akpm@linux-foundation.org \
--cc=davidlohr@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox