From patchwork Tue Sep 15 16:13:30 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 53684 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-lb0-f198.google.com (mail-lb0-f198.google.com [209.85.217.198]) by patches.linaro.org (Postfix) with ESMTPS id 1148222DE5 for ; Tue, 15 Sep 2015 16:14:02 +0000 (UTC) Received: by lbbmp1 with SMTP id mp1sf58887773lbb.2 for ; Tue, 15 Sep 2015 09:14:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=v//+Qz7xIj4pS3OO873gLy/dgmGHpE4tq5ky4zgoASk=; b=WBtinVDy/4JBirEQDFdm5JIAKZw2SoVG/VejtJSPl+254gxbjoc0mPh1V4GvE1YQue JUohggG0PS+ARpVq6HmVAGNGmvdYZvV+l2AGtAifJ/Ffiio49E/ybrfBAq+rAOdNEU7W DQvthugqbMbma/veAZgCUn3/BgxlAq08AaBOBF4DlM7S8grRNZChKQ/mu4B5u7wcV37M xCRdgh/s21wqnP+C9ZyqgXU+ruL9QHRfgKcaVip1G+amRbN/NuMvFttH1PKnRS4o/PKV lCjDp7hDIEMNLFhKiLPvH/DVkldQqvQ9c76IzK5gqVxb4uV7CguaHwGzoCd2UJjuLFLY Rm7w== X-Gm-Message-State: ALoCoQmAAS1cKrvtANmEnkAZXEwp1i/A5NE3oWYjnI3Du5/cA4fxkL0DWzMc5BltXbfj3ZQsb8Lx X-Received: by 10.194.118.65 with SMTP id kk1mr4456770wjb.5.1442333640962; Tue, 15 Sep 2015 09:14:00 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.23.200 with SMTP id o8ls846090laf.3.gmail; Tue, 15 Sep 2015 09:14:00 -0700 (PDT) X-Received: by 10.152.5.170 with SMTP id t10mr7860904lat.112.1442333640692; Tue, 15 Sep 2015 09:14:00 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com. [209.85.215.52]) by mx.google.com with ESMTPS id xv11si9389163lab.53.2015.09.15.09.14.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 09:14:00 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; Received: by lanb10 with SMTP id b10so110453422lan.3 for ; Tue, 15 Sep 2015 09:14:00 -0700 (PDT) X-Received: by 10.152.18.130 with SMTP id w2mr13137414lad.88.1442333640533; Tue, 15 Sep 2015 09:14:00 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.59.35 with SMTP id w3csp1899213lbq; Tue, 15 Sep 2015 09:13:59 -0700 (PDT) X-Received: by 10.68.189.198 with SMTP id gk6mr6952881pbc.141.1442333639460; Tue, 15 Sep 2015 09:13:59 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pg2si3559672pbb.36.2015.09.15.09.13.58; Tue, 15 Sep 2015 09:13:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754587AbbIOQNz (ORCPT + 29 others); Tue, 15 Sep 2015 12:13:55 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:44139 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752786AbbIOQNx (ORCPT ); Tue, 15 Sep 2015 12:13:53 -0400 Received: from edgewater-inn.cambridge.arm.com (edgewater-inn.cambridge.arm.com [10.1.203.139]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id t8FGDPwo005381; Tue, 15 Sep 2015 17:13:25 +0100 (BST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 3B0D61AE33C7; Tue, 15 Sep 2015 17:13:31 +0100 (BST) From: Will Deacon To: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Will Deacon , "Paul E. McKenney" , Peter Zijlstra Subject: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Date: Tue, 15 Sep 2015 17:13:30 +0100 Message-Id: <1442333610-16228-1-git-send-email-will.deacon@arm.com> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: will.deacon@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.52 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , As much as we'd like to live in a world where RELEASE -> ACQUIRE is always cheaply ordered and can be used to construct UNLOCK -> LOCK definitions with similar guarantees, the grim reality is that this isn't even possible on x86 (thanks to Paul for bringing us crashing down to Earth). This patch handles the issue by introducing a new barrier macro, smp_mb__release_acquire, that can be placed between a RELEASE and a subsequent ACQUIRE operation in order to upgrade them to a full memory barrier. At the moment, it doesn't have any users, so its existence serves mainly as a documentation aid. Documentation/memory-barriers.txt is updated to describe more clearly the ACQUIRE and RELEASE ordering in this area and to show an example of the new barrier in action. Cc: Paul E. McKenney Cc: Peter Zijlstra Signed-off-by: Will Deacon --- Following our discussion at [1], I thought I'd try to write something down... [1] http://lkml.kernel.org/r/20150828104854.GB16853@twins.programming.kicks-ass.net Documentation/memory-barriers.txt | 23 ++++++++++++++++++++++- arch/powerpc/include/asm/barrier.h | 1 + arch/x86/include/asm/barrier.h | 2 ++ include/asm-generic/barrier.h | 4 ++++ 4 files changed, 29 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 2ba8461b0631..46a85abb77c6 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -459,11 +459,18 @@ And a couple of implicit varieties: RELEASE on that same variable are guaranteed to be visible. In other words, within a given variable's critical section, all accesses of all previous critical sections for that variable are guaranteed to have - completed. + completed. If the RELEASE and ACQUIRE operations act on independent + variables, an smp_mb__release_acquire() barrier can be placed between + them to upgrade the sequence to a full barrier. This means that ACQUIRE acts as a minimal "acquire" operation and RELEASE acts as a minimal "release" operation. +A subset of the atomic operations described in atomic_ops.txt have ACQUIRE +and RELEASE variants in addition to fully-ordered and relaxed definitions. +For compound atomics performing both a load and a store, ACQUIRE semantics +apply only to the load and RELEASE semantics only to the store portion of +the operation. Memory barriers are only required where there's a possibility of interaction between two CPUs or between a CPU and a device. If it can be guaranteed that @@ -1895,6 +1902,20 @@ the RELEASE would simply complete, thereby avoiding the deadlock. a sleep-unlock race, but the locking primitive needs to resolve such races properly in any case. +If necessary, ordering can be enforced by use of an +smp_mb__release_acquire() barrier: + + *A = a; + RELEASE M + smp_mb__release_acquire(); + ACQUIRE N + *B = b; + +in which case, the only permitted sequences are: + + STORE *A, RELEASE M, ACQUIRE N, STORE *B + STORE *A, ACQUIRE N, RELEASE M, STORE *B + Locks and semaphores may not provide any guarantee of ordering on UP compiled systems, and so cannot be counted on in such a situation to actually achieve anything at all - especially with respect to I/O accesses - unless combined diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h index 0eca6efc0631..919624634d0a 100644 --- a/arch/powerpc/include/asm/barrier.h +++ b/arch/powerpc/include/asm/barrier.h @@ -87,6 +87,7 @@ do { \ ___p1; \ }) +#define smp_mb__release_acquire() smp_mb() #define smp_mb__before_atomic() smp_mb() #define smp_mb__after_atomic() smp_mb() #define smp_mb__before_spinlock() smp_mb() diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h index 0681d2532527..1c61ad251e0e 100644 --- a/arch/x86/include/asm/barrier.h +++ b/arch/x86/include/asm/barrier.h @@ -85,6 +85,8 @@ do { \ ___p1; \ }) +#define smp_mb__release_acquire() smp_mb() + #endif /* Atomic operations are already serializing on x86 */ diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index b42afada1280..61ae95199397 100644 --- a/include/asm-generic/barrier.h +++ b/include/asm-generic/barrier.h @@ -119,5 +119,9 @@ do { \ ___p1; \ }) +#ifndef smp_mb__release_acquire +#define smp_mb__release_acquire() do { } while (0) +#endif + #endif /* !__ASSEMBLY__ */ #endif /* __ASM_GENERIC_BARRIER_H */