From patchwork Wed Sep 16 11:07:06 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 53726 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 DB32222DB2 for ; Wed, 16 Sep 2015 11:07:14 +0000 (UTC) Received: by lbbmp1 with SMTP id mp1sf67940328lbb.2 for ; Wed, 16 Sep 2015 04:07:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=gxEZ13q6LdqkDd13u+UO8E9Cv5fZzBru5SZrA6b3h/w=; b=CkDd7FvupGIsJUOVIPBdNeIVJD6GFci5bgTcGT9SuFWT3k0igEzsT2bGOBGyxp8aDi wVMOqZ3ro04g2HBEXohXsvrqi5SobnMNvydh1hB1KOmh8TjBsxoVsgttckQX0s3Fue6s 7qXKnxBSMlVq6kN/AU2fuPSAZRT6meQW8CGcdYdEAKj7CAIHvAfyI31TCukgta891M2T QsOB6X99EH4nGkceVnPi0uQbuhXgFGPG+NHS7J0rPaxCOT9XmUzpYkjYrOfvXmR4vy9L JR3+Q0Qbp827k267M0SRMOvYTGsIZvkr1mLJHHBwLxIiD7XJIXYtgGVtRtk3lrEfSwc8 lGrw== X-Gm-Message-State: ALoCoQn3BKfUTVEclmWf2p67CzG0q+R8F6vCx4HS7zp3NwnXm4pI5idfnM5BhZFbCfcR7FAe2TEu X-Received: by 10.180.8.135 with SMTP id r7mr1847728wia.0.1442401633458; Wed, 16 Sep 2015 04:07:13 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.28.66 with SMTP id z2ls822856lag.76.gmail; Wed, 16 Sep 2015 04:07:13 -0700 (PDT) X-Received: by 10.152.120.164 with SMTP id ld4mr28133625lab.84.1442401633219; Wed, 16 Sep 2015 04:07:13 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com. [209.85.217.182]) by mx.google.com with ESMTPS id sk1si17839045lbb.44.2015.09.16.04.07.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 04:07:13 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.217.182 as permitted sender) client-ip=209.85.217.182; Received: by lbpo4 with SMTP id o4so101500737lbp.2 for ; Wed, 16 Sep 2015 04:07:13 -0700 (PDT) X-Received: by 10.152.26.98 with SMTP id k2mr27741722lag.41.1442401633050; Wed, 16 Sep 2015 04:07:13 -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 w3csp2374669lbq; Wed, 16 Sep 2015 04:07:11 -0700 (PDT) X-Received: by 10.66.252.131 with SMTP id zs3mr57795663pac.75.1442401631633; Wed, 16 Sep 2015 04:07:11 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bx2si39908387pab.140.2015.09.16.04.07.10; Wed, 16 Sep 2015 04:07:11 -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 S1753955AbbIPLHH (ORCPT + 29 others); Wed, 16 Sep 2015 07:07:07 -0400 Received: from foss.arm.com ([217.140.101.70]:54954 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753099AbbIPLHE (ORCPT ); Wed, 16 Sep 2015 07:07:04 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA6BC56C; Wed, 16 Sep 2015 04:07:19 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1A7513F57E; Wed, 16 Sep 2015 04:07:02 -0700 (PDT) Date: Wed, 16 Sep 2015 12:07:06 +0100 From: Will Deacon To: Peter Zijlstra Cc: "Paul E. McKenney" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Message-ID: <20150916110706.GF28771@arm.com> References: <1442333610-16228-1-git-send-email-will.deacon@arm.com> <20150915174724.GP4029@linux.vnet.ibm.com> <20150916091452.GC3816@twins.programming.kicks-ass.net> <20150916102908.GA28771@arm.com> <20150916104314.GA3604@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150916104314.GA3604@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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.217.182 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: , On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote: > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote: > > > Indeed, that is a hole in the definition, that I think we should close. > > > I'm struggling to understand the hole, but here's my intuition. If an > > ACQUIRE on CPUx reads from a RELEASE by CPUy, then I'd expect CPUx to > > observe all memory accessed performed by CPUy prior to the RELEASE > > before it observes the RELEASE itself, regardless of this new barrier. > > I think this matches what we currently have in memory-barriers.txt (i.e. > > acquire/release are neither transitive or multi-copy atomic). > > Ah agreed. I seem to have gotten my brain in a tangle. > > Basically where a program order release+acquire relies on an address > dependency, a cross cpu release+acquire relies on causality. If we > observe the release, we must also observe everything prior to it etc. Yes, and crucially, the "everything prior to it" only encompasses accesses made by the releasing CPU itself (in the absence of other barriers and synchronisation). Given that we managed to get confused, it doesn't hurt to call this out explicitly in the doc, so I can add the following extra text. Will --->8 --- 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/ diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 46a85abb77c6..794d102d06df 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1902,8 +1902,8 @@ 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: +Where the RELEASE and ACQUIRE operations are performed by the same CPU, +ordering can be enforced by use of an smp_mb__release_acquire() barrier: *A = a; RELEASE M @@ -1916,6 +1916,10 @@ in which case, the only permitted sequences are: STORE *A, RELEASE M, ACQUIRE N, STORE *B STORE *A, ACQUIRE N, RELEASE M, STORE *B +Note that smp_mb__release_acquire() has no effect on ACQUIRE or RELEASE +operations performed by other CPUs, even if they are to the same variable. +In cases where transitivity is required, smp_mb() should be used explicitly. + 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