From: Chris Metcalf <cmetcalf@ezchip.com>
To: Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
"mtk.manpages@gmail.com" <mtk.manpages@gmail.com>,
"dvhart@infradead.org" <dvhart@infradead.org>,
"dave@stgolabs.net" <dave@stgolabs.net>,
"Vineet.Gupta1@synopsys.com" <Vineet.Gupta1@synopsys.com>,
"ralf@linux-mips.org" <ralf@linux-mips.org>,
"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
<linux@arm.linux.org.uk>, <rth@twiddle.net>
Subject: Re: futex atomic vs ordering constraints
Date: Wed, 2 Sep 2015 12:10:58 -0400 [thread overview]
Message-ID: <55E71F92.4000001@ezchip.com> (raw)
In-Reply-To: <20150902125555.GT16853@twins.programming.kicks-ass.net>
On 09/02/2015 08:55 AM, Peter Zijlstra wrote:
> So here goes..
>
> Chris, I'm awfully sorry, but I seem to be Tile challenged.
>
> TileGX seems to define:
>
> #define smp_mb__before_atomic() smp_mb()
> #define smp_mb__after_atomic() smp_mb()
>
> However, its atomic_add_return() implementation looks like:
>
> static inline int atomic_add_return(int i, atomic_t *v)
> {
> int val;
> smp_mb(); /* barrier for proper semantics */
> val = __insn_fetchadd4((void *)&v->counter, i) + i;
> barrier(); /* the "+ i" above will wait on memory */
> return val;
> }
>
> Which leaves me confused on smp_mb__after_atomic().
Are you concerned about whether it has proper memory
barrier semantics already, i.e. full barriers before and after?
In fact we do have a full barrier before, but then because of the
"+ i" / "barrier()", we know that the only other operation since
the previous mb(), namely the read of v->counter, has
completed after the atomic operation. As a result we can
omit explicitly having a second barrier.
It does seem like all the current memory-order semantics are
correct, unless I'm missing something!
> That said, your futex ops seem to lack any memory barrier, so naively
> I'd add both, its just that your add_return() confuses me.
So something like this?
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b69cb1..0a5501b11d02 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -39,6 +39,7 @@
#ifdef __tilegx__
#define __futex_asm(OP) \
+ smp_mb(); \
asm("1: {" #OP " %1, %3, %4; movei %0, 0 }\n" \
".pushsection .fixup,\"ax\"\n" \
"0: { movei %0, %5; j 9f }\n" \
@@ -48,7 +49,8 @@
".popsection\n" \
"9:" \
: "=r" (ret), "=r" (val), "+m" (*(uaddr)) \
- : "r" (uaddr), "r" (oparg), "i" (-EFAULT))
+ : "r" (uaddr), "r" (oparg), "i" (-EFAULT)); \
+ smp_mb()
#define __futex_set() __futex_asm(exch4)
#define __futex_add() __futex_asm(fetchadd4)
@@ -75,7 +77,10 @@
#define __futex_call(FN) \
{ \
- struct __get_user gu = FN((u32 __force *)uaddr, lock, oparg); \
+ struct __get_user gu; \
+ smp_mb(); \
+ gu = FN((u32 __force *)uaddr, lock, oparg); \
+ /* See smp_mb__after_atomic() */ \
val = gu.val; \
ret = gu.err; \
}
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
next prev parent reply other threads:[~2015-09-02 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 18:16 futex atomic vs ordering constraints Peter Zijlstra
2015-08-29 1:33 ` Davidlohr Bueso
2015-09-01 16:38 ` Peter Zijlstra
2015-09-01 16:31 ` Will Deacon
2015-09-01 16:42 ` Peter Zijlstra
2015-09-01 16:47 ` Will Deacon
2015-09-01 19:05 ` Thomas Gleixner
2015-09-02 12:55 ` Peter Zijlstra
2015-09-02 16:10 ` Chris Metcalf [this message]
2015-09-02 17:00 ` Peter Zijlstra
2015-09-02 17:25 ` Chris Metcalf
2015-09-02 21:18 ` Linus Torvalds
2015-09-04 17:25 ` Chris Metcalf
2015-09-05 17:53 ` Peter Zijlstra
2015-09-07 9:30 ` Will Deacon
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=55E71F92.4000001@ezchip.com \
--to=cmetcalf@ezchip.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=dave@stgolabs.net \
--cc=ddaney@caviumnetworks.com \
--cc=dvhart@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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.