From: Peter Zijlstra <peterz@infradead.org>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Michel Lespinasse <walken@google.com>,
arc-linux-dev@synopsys.com, lkml <linux-kernel@vger.kernel.org>,
David Hildenbrand <dahi@linux.vnet.ibm.com>,
Will Deacon <will.deacon@arm.com>,
ralf@linux-mips.org, ddaney@caviumnetworks.com
Subject: Re: [PATCH 1/4] ARC: add barriers to futex code
Date: Fri, 7 Aug 2015 13:40:47 +0200 [thread overview]
Message-ID: <20150807114047.GD18673@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150806134826.GF25159@twins.programming.kicks-ass.net>
On Thu, Aug 06, 2015 at 03:48:26PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 06, 2015 at 06:05:20PM +0530, Vineet Gupta wrote:
> > The atomic ops on futex need to provide the full barrier just like
> > regular atomics in kernel.
> >
> > Also remove pagefault_enable/disable in futex_atomic_cmpxchg_inatomic()
> > as core code already does that
>
> Urgh, and of course tglx just left for holidays :-)
>
> > +++ b/arch/arc/include/asm/futex.h
> > @@ -20,6 +20,7 @@
> >
> > #define __futex_atomic_op(insn, ret, oldval, uaddr, oparg)\
> > \
> > + smp_mb(); \
> > __asm__ __volatile__( \
> > "1: llock %1, [%2] \n" \
> > insn "\n" \
> > @@ -40,12 +41,14 @@
> > \
> > : "=&r" (ret), "=&r" (oldval) \
> > : "r" (uaddr), "r" (oparg), "ir" (-EFAULT) \
> > - : "cc", "memory")
> > + : "cc", "memory"); \
> > + smp_mb(); \
> >
>
>
> So:
>
> - alhpa: only has the first smp_mb(), suggesting RELEASE
> - arm: only has the first smp_mb(), suggesting RELEASE
> - arm64: has store-release + smp_mb(), suggesting full barriers
> - MIPS: has LLSC_MB after, suggesting ACQUIRE
> - powerpc: lwsync before, sync after, full barrier
>
> x86 is of course boring and fully ordered
>
> Looking at the usage site of futex_atomic_op_inuser(), that's in
> futex_wake_op() which might suggest RELEASE is indeed sufficient.
>
> Which leaves me puzzled on MIPS, but what do I know.
So I _think_ the MIPS code is broken. The mips futex code is from 2006
and the mips smp_mb__before_llsc bits are from 2010, so its well
possible this was missed.
Ralf, David, did I miss the obvious or does the below patch make sense?
---
Subject: MIPS: Fix __futex_atomic_op() for WEAK_REORDERING_BEYOND_LLSC
Current __futex_atomic_op() doesn't have smp_mb__before_llsc(), meaning
it would allow prior load/stores to escape out and re-order against the
ll/sc itself.
While the exact requirements on __futex_atomic_op() are a little unclear
at the moment it must be either RELEASE or fully ordered, without
smp_mb__before_llsc() the MIPS code is neither.
Therefore add smp_mb__before_llsc().
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
arch/mips/include/asm/futex.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/include/asm/futex.h b/arch/mips/include/asm/futex.h
index 1de190bdfb9c..2b8023b9b661 100644
--- a/arch/mips/include/asm/futex.h
+++ b/arch/mips/include/asm/futex.h
@@ -20,6 +20,8 @@
#define __futex_atomic_op(insn, ret, oldval, uaddr, oparg) \
{ \
+ smp_mb__before_llsc(); \
+ \
if (cpu_has_llsc && R10000_LLSC_WAR) { \
__asm__ __volatile__( \
" .set push \n" \
next prev parent reply other threads:[~2015-08-07 11:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 12:35 [PATCH 0/4] ARC futex fixes Vineet Gupta
2015-08-06 12:35 ` [PATCH 1/4] ARC: add barriers to futex code Vineet Gupta
2015-08-06 13:15 ` David Hildenbrand
2015-08-06 13:28 ` Vineet Gupta
2015-08-06 13:48 ` Peter Zijlstra
2015-08-06 14:11 ` Will Deacon
2015-08-07 11:40 ` Peter Zijlstra [this message]
2015-08-06 12:35 ` [PATCH 2/4] ARC: futex cosmetics Vineet Gupta
2015-08-06 12:35 ` [PATCH 3/4] ARC: make futex_atomic_cmpxchg_inatomic() return bimodal Vineet Gupta
2015-08-06 12:35 ` [PATCH 4/4] ARC: Enable HAVE_FUTEX_CMPXCHG Vineet Gupta
2015-08-06 13:46 ` [PATCH 5/4] ARC: ensure futex ops are atomic in !LLSC config Vineet Gupta
2015-08-17 7:46 ` [PATCH 0/4] ARC futex fixes Vineet Gupta
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=20150807114047.GD18673@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Vineet.Gupta1@synopsys.com \
--cc=arc-linux-dev@synopsys.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=ddaney@caviumnetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=tglx@linutronix.de \
--cc=walken@google.com \
--cc=will.deacon@arm.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