Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754696AbbHFOLp (ORCPT ); Thu, 6 Aug 2015 10:11:45 -0400 Received: from foss.arm.com ([217.140.101.70]:38512 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754564AbbHFOLn (ORCPT ); Thu, 6 Aug 2015 10:11:43 -0400 Date: Thu, 6 Aug 2015 15:11:42 +0100 From: Will Deacon To: Peter Zijlstra Cc: Vineet Gupta , Thomas Gleixner , Michel Lespinasse , "arc-linux-dev@synopsys.com" , lkml , David Hildenbrand , "ralf@linux-mips.org" Subject: Re: [PATCH 1/4] ARC: add barriers to futex code Message-ID: <20150806141142.GE25483@arm.com> References: <1438864523-31340-1-git-send-email-vgupta@synopsys.com> <1438864523-31340-2-git-send-email-vgupta@synopsys.com> <20150806134826.GF25159@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150806134826.GF25159@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2195 Lines: 67 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/