Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp785630yba; Fri, 3 May 2019 10:24:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqz08Sj4KLpLxBpuxkBGnieR3YvuCWJCwDh+OZlq7L2xs0ixdzRXlDmbF7GGOi/xDSYFNNVE X-Received: by 2002:a65:6686:: with SMTP id b6mr12068476pgw.419.1556904240576; Fri, 03 May 2019 10:24:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556904240; cv=none; d=google.com; s=arc-20160816; b=FQa3QiYPhY5iBkHwbtGS7sGKXwiNpf92HIKkGGyqIAbGbANaJIZz4uCCD21o1HWHiL NKlIzEUSus/h4x9X8fJfAur30yufjbNwWRMkCtXCfJhsvqgZ9e3cTeH879p8Fs1GGkU3 6asPezEYytyClhJfNM5jTj8KgRdWA4oTyqIARvUSekDJghnRE6iYJ5F4g5p6lk1dse7D bj3qXcqqrMF9rLPooquUTlDa4tAIQGM0MnlC+2XN4oVMD04P5HoEGEIACcW/BX3ZDDed +QNThW2qCZNsbooUJpuBfSgU7eYrKY8dTLnxtTuWWPqalPaPvQOMM8fklYDQgr+wNTtk ia0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=Vz88eF4SlSyF1JOYZshAsOZhB52eXEQGbIWgHaXTquM=; b=uaWUPw1XNWJWwI/Fc0eR1TZu9j83oZaNj1LcMYbbwsIG26WNgV6wuUFd9yFepZR1NT f13aCDCpLrautwRFyqmQGk/cMmsvj+4zUmNVOQXWW1AF91Ww+Ffysts4E4HmEyadlOfL dLMZ4jBtZhm+JD+m8pJB+Sz4enE3q6iEXtxDvk8SfSnT22JgfrTMcwQ5A2mRDPSTVk4y eAUiQhwzVjiOQdmXFAIyLAgNz5uw8wy+EqFuVSDVuZBcKmAXhRNpL1sySW4pxW41pStO z07PU0hh1pG5CXDjc+Yf5sunJCYBQBkAwGZhzkUPQRS0hluM/H5FLkDdnARQehAyNBnr b9hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g90si3153328plb.140.2019.05.03.10.23.45; Fri, 03 May 2019 10:24:00 -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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728524AbfECRNq (ORCPT + 99 others); Fri, 3 May 2019 13:13:46 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:58728 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727628AbfECRNp (ORCPT ); Fri, 3 May 2019 13:13:45 -0400 Received: (qmail 6340 invoked by uid 2102); 3 May 2019 13:13:44 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 May 2019 13:13:44 -0400 Date: Fri, 3 May 2019 13:13:44 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Paul E. McKenney" cc: LKMM Maintainers -- Akira Yokosawa , Andrea Parri , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Peter Zijlstra , Will Deacon , Kernel development list Subject: [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic() In-Reply-To: <20190503163411.GH2606@hirez.programming.kicks-ass.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The description of smp_mb__before_atomic() and smp_mb__after_atomic() in Documentation/atomic_t.txt is slightly terse and misleading. It does not clearly state which other instructions are ordered by these barriers. This improves the text to make the actual ordering implications clear, and also to explain how these barriers differ from a RELEASE or ACQUIRE ordering. Signed-off-by: Alan Stern CC: Peter Zijlstra --- v2: Update the explanation: These barriers do provide order for accesses on the far side of the atomic RMW operation. Documentation/atomic_t.txt | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) Index: usb-devel/Documentation/atomic_t.txt =================================================================== --- usb-devel.orig/Documentation/atomic_t.txt +++ usb-devel/Documentation/atomic_t.txt @@ -170,8 +170,14 @@ The barriers: smp_mb__{before,after}_atomic() -only apply to the RMW ops and can be used to augment/upgrade the ordering -inherent to the used atomic op. These barriers provide a full smp_mb(). +only apply to the RMW atomic ops and can be used to augment/upgrade the +ordering inherent to the op. These barriers act almost like a full smp_mb(): +smp_mb__before_atomic() orders all earlier accesses against the RMW op +itself and all accesses following it, and smp_mb__after_atomic() orders all +later accesses against the RMW op and all accesses preceding it. However, +accesses between the smp_mb__{before,after}_atomic() and the RMW op are not +ordered, so it is advisable to place the barrier right next to the RMW atomic +op whenever possible. These helper barriers exist because architectures have varying implicit ordering on their SMP atomic primitives. For example our TSO architectures @@ -195,7 +201,9 @@ Further, while something like: atomic_dec(&X); is a 'typical' RELEASE pattern, the barrier is strictly stronger than -a RELEASE. Similarly for something like: +a RELEASE because it orders preceding instructions against both the read +and write parts of the atomic_dec(), and against all following instructions +as well. Similarly, something like: atomic_inc(&X); smp_mb__after_atomic(); @@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus This should not happen; but a hypothetical atomic_inc_acquire() -- (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome, -since then: +because it would not order the W part of the RMW against the following +WRITE_ONCE. Thus: P1 P2