public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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"	\

  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