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. At the very least this patch isn't wrong, fully ordered is sufficient. -- 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/
