On Thu, Aug 06, 2015 at 02:48:26PM +0100, 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 :-)
Damn, he's really missing out on this! > > +++ 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 I'd be ok relaxing that to smp_mb() but I don't think I'm brave enough to go all the way to an STLXR. You can lose SC if you combine explicit barrier instructions with the acquire/release instructions and I dread to think what userspace is doing... > - MIPS: has LLSC_MB after, suggesting ACQUIRE Yikes, so there's a fun semantic difference there. Maybe we should go look at glibc (which only uses one of the futex ops in pthread_cond_wait iirc). > - 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. > > At the very least this patch isn't wrong, fully ordered is sufficient. Agreed. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
