All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.