[2/2] docs: memory-barriers: Add note on plain-accesses to address-dependency barriers
Message ID | 20230803032408.2514989-2-joel@joelfernandes.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f41:0:b0:3e4:2afc:c1 with SMTP id v1csp890923vqx; Wed, 2 Aug 2023 20:51:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFJxWgIS4/+AEl3DM3N2xDbPty81yteeVmcle2NExy7Bx9hWl7Uz0UnoAzSNGMzhuEATpNn X-Received: by 2002:a05:6a00:1146:b0:687:8f50:47c8 with SMTP id b6-20020a056a00114600b006878f5047c8mr60074pfm.1.1691034664613; Wed, 02 Aug 2023 20:51:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691034664; cv=none; d=google.com; s=arc-20160816; b=UChBK4WzSFKznIzCTQ0t8b5FOO4AgR9ADBEEAbu6IBIJHGaxyxTQlb+CTShDpHkXzQ 0dOV+jyVQjg38ox+ex0Ih/jNzqqcGgoU0YPUs3jYaGGZEJg0fLJXUsa562tofB5DmYh6 5zsrav9xSijs8s6jGAmmMXqNsoxYsZPWQpWTYSkC64fnHgvuXXBQNQm8JK0IOq41S2wb MuAARa4Kn21Sd7RWAV3jGIbgOT0tCN00G9OVmMG8kVwaY+qg+h9KFweV288z9XWJ0kN5 Yw6mFVOSe7pTcUYSCWC0ElA4K+vgrKbeg8jBa6bkZ8Kyg2Hb0rNQnbCcfm19yFL7tjgW YXWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=VMHqujoTuT0RsHzRdVhgkyPvYcb4Kgnj2rbEthA3RMM=; fh=sf39n9bsV4nar1ajgOioZpKGkdoMgqPPMO5CkgmtHE4=; b=lnJi9eJILvFe8iuJ9jfwcEqfAWQAZ0OClR4wDWxCJeK6yzb7jd8nCx1ehcYlVtkLSJ zSxT9PG8iegMPcU3wmjZVpXaQlYNlYUv/p3ECyDjoyoV3o7SYsNOWaFo5ktusR0MT2ox yCqA8pu3SYvzM2IyldF6ih4aRrSwf+pSkq/HX9XFUoD1SI+ICsxdMrqNYsdjlJgHD8QU fwpMyMyUDAS5iaf+x1TGbB94eisv4cRhKJtWaQUXFuNgpTs19/ico3/LErYO+6tu8dLj upWqMdjfH9v1NmbtuRZcp+UY275n1UA+ldk+zq+VXkyvbts5T04cPkTIPwnIWxQbIdfx HL2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=jmOMCg3a; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w7-20020a637b07000000b005643758e9c9si1008819pgc.515.2023.08.02.20.50.50; Wed, 02 Aug 2023 20:51:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=jmOMCg3a; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233523AbjHCDYb (ORCPT <rfc822;cambridge8321@gmail.com> + 99 others); Wed, 2 Aug 2023 23:24:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233194AbjHCDYS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 2 Aug 2023 23:24:18 -0400 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0305826B2 for <linux-kernel@vger.kernel.org>; Wed, 2 Aug 2023 20:24:16 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-bc379e4c1cbso488439276.2 for <linux-kernel@vger.kernel.org>; Wed, 02 Aug 2023 20:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1691033055; x=1691637855; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VMHqujoTuT0RsHzRdVhgkyPvYcb4Kgnj2rbEthA3RMM=; b=jmOMCg3aY1NdBWQ0E/xfB3w00lqf6WPH+O3dT/+EXyF79Cpvo08Pb1daWoPjBSPZT6 bqocWqfWMdrhrDRwxYzLemMLfNLaTPpNFlqm6gyTOU4N5ITwyrd3vSnmCCD0lcK8XGzR 5WD5DZc70Rq0qy8ulzg0neW+ZH1ryoSqFeF8A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691033055; x=1691637855; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VMHqujoTuT0RsHzRdVhgkyPvYcb4Kgnj2rbEthA3RMM=; b=UOJXTidWeqLqqUy2WqXoPDiXuokPSipCU/pq63EYnLEw7pcNezNX87SAZAHpb0kR44 TcFDdjDh7B9TF7RKoRLFX1GVKjd+w7veyl2x6htFy/oPkxSt1icbY/TJoxV0lzfACvlD 0jwSlCJPTpGPNMt83qBjxI4TzzFx9HPcV10AEokTT0f0rCCRuVjWb0YSp2dO0fYeRlle xoCZpURvqXE0CZDEU4XyOxmcByh+Xz5HxNeeut+MgUKJCjWA0TgYnUI3oS+c2FVrWjSb 9ZHCQBehWIvEk6d2kmr1pCjHFUL3MB+NwNEwkNCBkYpRt79x6uAgWyJlkLpZoA2rmI3q 1HFw== X-Gm-Message-State: ABy/qLYAPWAK6/GSKgVyLzthoqVjEHjLSbuKwZmbN+rbmA78+5qFU7ko SQgeNDiVOhZ1K0aatCI7BZxYvELhM92wkEAKHNs= X-Received: by 2002:a25:d401:0:b0:d15:a265:4c43 with SMTP id m1-20020a25d401000000b00d15a2654c43mr18622880ybf.61.1691033054767; Wed, 02 Aug 2023 20:24:14 -0700 (PDT) Received: from joelboxx5.c.googlers.com.com (156.190.123.34.bc.googleusercontent.com. [34.123.190.156]) by smtp.gmail.com with ESMTPSA id a14-20020a02ac0e000000b0042b67b12363sm4535176jao.37.2023.08.02.20.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Aug 2023 20:24:13 -0700 (PDT) From: "Joel Fernandes (Google)" <joel@joelfernandes.org> To: linux-kernel@vger.kernel.org, rcu@vger.kernel.org Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>, Alan Stern <stern@rowland.harvard.edu>, Andrea Parri <parri.andrea@gmail.com>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Boqun Feng <boqun.feng@gmail.com>, Nicholas Piggin <npiggin@gmail.com>, David Howells <dhowells@redhat.com>, Jade Alglave <j.alglave@ucl.ac.uk>, Luc Maranget <luc.maranget@inria.fr>, "Paul E. McKenney" <paulmck@kernel.org>, Akira Yokosawa <akiyks@gmail.com>, Daniel Lustig <dlustig@nvidia.com>, Jonathan Corbet <corbet@lwn.net> Subject: [PATCH 2/2] docs: memory-barriers: Add note on plain-accesses to address-dependency barriers Date: Thu, 3 Aug 2023 03:24:07 +0000 Message-ID: <20230803032408.2514989-2-joel@joelfernandes.org> X-Mailer: git-send-email 2.41.0.585.gd2178a4bd4-goog In-Reply-To: <20230803032408.2514989-1-joel@joelfernandes.org> References: <20230803032408.2514989-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773178364751092999 X-GMAIL-MSGID: 1773178364751092999 |
Series |
[1/2] docs: rcu: Add cautionary note on plain-accesses to requirements
|
|
Commit Message
Joel Fernandes
Aug. 3, 2023, 3:24 a.m. UTC
The compiler has the ability to cause misordering by destroying
address-dependency barriers if comparison operations are used. Add a
note about this to memory-barriers.txt and point to rcu-dereference.rst
for more information.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
Documentation/memory-barriers.txt | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Thu, Aug 03, 2023 at 03:24:07AM +0000, Joel Fernandes (Google) wrote: > The compiler has the ability to cause misordering by destroying > address-dependency barriers if comparison operations are used. Add a > note about this to memory-barriers.txt and point to rcu-dereference.rst > for more information. > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > --- > Documentation/memory-barriers.txt | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index 06e14efd8662..acc8ec5ce563 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: > variables such as READ_ONCE() and rcu_dereference() provide implicit > address-dependency barriers. > > + [!] Note that address dependency barriers can be destroyed by comparison > + of a pointer obtained by a marked accessor such as READ_ONCE() or > + rcu_dereference() with some value. For an example of this, see > + rcu_dereference.rst (part where the comparison of pointers is discussed). Hmmm... Given that this is in a section marked "historical" (for the old smp_read_barrier_depends() API), why not instead add a pointer to Documentation/RCU/rcu_dereference.rst to the beginning of the section, noted as the updated material? Thanx, Paul > + > (3) Read (or load) memory barriers. > > A read barrier is an address-dependency barrier plus a guarantee that all > -- > 2.41.0.585.gd2178a4bd4-goog >
On Thu, Aug 03, 2023 at 11:52:06AM -0700, Paul E. McKenney wrote: > On Thu, Aug 03, 2023 at 03:24:07AM +0000, Joel Fernandes (Google) wrote: > > The compiler has the ability to cause misordering by destroying > > address-dependency barriers if comparison operations are used. Add a > > note about this to memory-barriers.txt and point to rcu-dereference.rst > > for more information. > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > --- > > Documentation/memory-barriers.txt | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > index 06e14efd8662..acc8ec5ce563 100644 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: > > variables such as READ_ONCE() and rcu_dereference() provide implicit > > address-dependency barriers. > > > > + [!] Note that address dependency barriers can be destroyed by comparison > > + of a pointer obtained by a marked accessor such as READ_ONCE() or > > + rcu_dereference() with some value. For an example of this, see > > + rcu_dereference.rst (part where the comparison of pointers is discussed). > > Hmmm... > > Given that this is in a section marked "historical" (for the old > smp_read_barrier_depends() API), why not instead add a pointer to > Documentation/RCU/rcu_dereference.rst to the beginning of the section, > noted as the updated material? Sounds good. There's also another section in the same file on Address dependency barriers (also marked historical). So something like the following? ---8<----------------------- diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index acc8ec5ce563..ba50220716ca 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties: (2) Address-dependency barriers (historical). + [!] This section is marked as HISTORICAL: For more up-to-date + information, including how compiler transformations related to pointer + comparisons can sometimes cause problems, see + Documentation/RCU/rcu_dereference.rst. An address-dependency barrier is a weaker form of read barrier. In the case where two loads are performed such that the second depends on the @@ -561,6 +565,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee: ADDRESS-DEPENDENCY BARRIERS (HISTORICAL) ---------------------------------------- +[!] This section is marked as HISTORICAL: For more up-to-date information, +including how compiler transformations related to pointer comparisons can +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst. As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for DEC Alpha, which means that about the only people who need to pay attention
On Fri, Aug 04, 2023 at 05:11:27AM +0000, Joel Fernandes wrote: > On Thu, Aug 03, 2023 at 11:52:06AM -0700, Paul E. McKenney wrote: > > On Thu, Aug 03, 2023 at 03:24:07AM +0000, Joel Fernandes (Google) wrote: > > > The compiler has the ability to cause misordering by destroying > > > address-dependency barriers if comparison operations are used. Add a > > > note about this to memory-barriers.txt and point to rcu-dereference.rst > > > for more information. > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > --- > > > Documentation/memory-barriers.txt | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > > index 06e14efd8662..acc8ec5ce563 100644 > > > --- a/Documentation/memory-barriers.txt > > > +++ b/Documentation/memory-barriers.txt > > > @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: > > > variables such as READ_ONCE() and rcu_dereference() provide implicit > > > address-dependency barriers. > > > > > > + [!] Note that address dependency barriers can be destroyed by comparison > > > + of a pointer obtained by a marked accessor such as READ_ONCE() or > > > + rcu_dereference() with some value. For an example of this, see > > > + rcu_dereference.rst (part where the comparison of pointers is discussed). > > > > Hmmm... > > > > Given that this is in a section marked "historical" (for the old > > smp_read_barrier_depends() API), why not instead add a pointer to > > Documentation/RCU/rcu_dereference.rst to the beginning of the section, > > noted as the updated material? > > Sounds good. There's also another section in the same file on Address > dependency barriers (also marked historical). So something like the > following? Given a Signed-off-by and so forth, I would be happy to take this one. Thanx, Paul > ---8<----------------------- > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index acc8ec5ce563..ba50220716ca 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties: > > > (2) Address-dependency barriers (historical). > + [!] This section is marked as HISTORICAL: For more up-to-date > + information, including how compiler transformations related to pointer > + comparisons can sometimes cause problems, see > + Documentation/RCU/rcu_dereference.rst. > > An address-dependency barrier is a weaker form of read barrier. In the > case where two loads are performed such that the second depends on the > @@ -561,6 +565,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee: > > ADDRESS-DEPENDENCY BARRIERS (HISTORICAL) > ---------------------------------------- > +[!] This section is marked as HISTORICAL: For more up-to-date information, > +including how compiler transformations related to pointer comparisons can > +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst. > > As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for > DEC Alpha, which means that about the only people who need to pay attention
On Fri, Aug 04, 2023 at 06:52:32AM -0700, Paul E. McKenney wrote: > On Fri, Aug 04, 2023 at 05:11:27AM +0000, Joel Fernandes wrote: > > On Thu, Aug 03, 2023 at 11:52:06AM -0700, Paul E. McKenney wrote: > > > On Thu, Aug 03, 2023 at 03:24:07AM +0000, Joel Fernandes (Google) wrote: > > > > The compiler has the ability to cause misordering by destroying > > > > address-dependency barriers if comparison operations are used. Add a > > > > note about this to memory-barriers.txt and point to rcu-dereference.rst > > > > for more information. > > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > --- > > > > Documentation/memory-barriers.txt | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > > > index 06e14efd8662..acc8ec5ce563 100644 > > > > --- a/Documentation/memory-barriers.txt > > > > +++ b/Documentation/memory-barriers.txt > > > > @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: > > > > variables such as READ_ONCE() and rcu_dereference() provide implicit > > > > address-dependency barriers. > > > > > > > > + [!] Note that address dependency barriers can be destroyed by comparison > > > > + of a pointer obtained by a marked accessor such as READ_ONCE() or > > > > + rcu_dereference() with some value. For an example of this, see > > > > + rcu_dereference.rst (part where the comparison of pointers is discussed). > > > > > > Hmmm... > > > > > > Given that this is in a section marked "historical" (for the old > > > smp_read_barrier_depends() API), why not instead add a pointer to > > > Documentation/RCU/rcu_dereference.rst to the beginning of the section, > > > noted as the updated material? > > > > Sounds good. There's also another section in the same file on Address > > dependency barriers (also marked historical). So something like the > > following? > > Given a Signed-off-by and so forth, I would be happy to take this one. Thank you for helping me improve the docs, here it goes: ---8<----------------------- From: "Joel Fernandes (Google)" <joel@joelfernandes.org> Subject: [PATCH] docs: memory-barriers: Add note on compiler transformation and address deps The compiler has the ability to cause misordering by destroying address-dependency barriers if comparison operations are used. Add a note about this to memory-barriers.txt in the beginning of both the historical address-dependency sections and point to rcu-dereference.rst for more information. Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> --- Documentation/memory-barriers.txt | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index acc8ec5ce563..ba50220716ca 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties: (2) Address-dependency barriers (historical). + [!] This section is marked as HISTORICAL: For more up-to-date + information, including how compiler transformations related to pointer + comparisons can sometimes cause problems, see + Documentation/RCU/rcu_dereference.rst. An address-dependency barrier is a weaker form of read barrier. In the case where two loads are performed such that the second depends on the @@ -561,6 +565,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee: ADDRESS-DEPENDENCY BARRIERS (HISTORICAL) ---------------------------------------- +[!] This section is marked as HISTORICAL: For more up-to-date information, +including how compiler transformations related to pointer comparisons can +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst. As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for DEC Alpha, which means that about the only people who need to pay attention
On Fri, Aug 04, 2023 at 04:27:45PM +0000, Joel Fernandes wrote: > On Fri, Aug 04, 2023 at 06:52:32AM -0700, Paul E. McKenney wrote: > > On Fri, Aug 04, 2023 at 05:11:27AM +0000, Joel Fernandes wrote: > > > On Thu, Aug 03, 2023 at 11:52:06AM -0700, Paul E. McKenney wrote: > > > > On Thu, Aug 03, 2023 at 03:24:07AM +0000, Joel Fernandes (Google) wrote: > > > > > The compiler has the ability to cause misordering by destroying > > > > > address-dependency barriers if comparison operations are used. Add a > > > > > note about this to memory-barriers.txt and point to rcu-dereference.rst > > > > > for more information. > > > > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > > --- > > > > > Documentation/memory-barriers.txt | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > > > > index 06e14efd8662..acc8ec5ce563 100644 > > > > > --- a/Documentation/memory-barriers.txt > > > > > +++ b/Documentation/memory-barriers.txt > > > > > @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: > > > > > variables such as READ_ONCE() and rcu_dereference() provide implicit > > > > > address-dependency barriers. > > > > > > > > > > + [!] Note that address dependency barriers can be destroyed by comparison > > > > > + of a pointer obtained by a marked accessor such as READ_ONCE() or > > > > > + rcu_dereference() with some value. For an example of this, see > > > > > + rcu_dereference.rst (part where the comparison of pointers is discussed). > > > > > > > > Hmmm... > > > > > > > > Given that this is in a section marked "historical" (for the old > > > > smp_read_barrier_depends() API), why not instead add a pointer to > > > > Documentation/RCU/rcu_dereference.rst to the beginning of the section, > > > > noted as the updated material? > > > > > > Sounds good. There's also another section in the same file on Address > > > dependency barriers (also marked historical). So something like the > > > following? > > > > Given a Signed-off-by and so forth, I would be happy to take this one. > > Thank you for helping me improve the docs, here it goes: > > ---8<----------------------- > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org> > Subject: [PATCH] docs: memory-barriers: Add note on compiler transformation > and address deps > > The compiler has the ability to cause misordering by destroying > address-dependency barriers if comparison operations are used. Add a > note about this to memory-barriers.txt in the beginning of both the > historical address-dependency sections and point to rcu-dereference.rst > for more information. > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Queued and pushed, thank you! Thanx, Paul > --- > Documentation/memory-barriers.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index acc8ec5ce563..ba50220716ca 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties: > > > (2) Address-dependency barriers (historical). > + [!] This section is marked as HISTORICAL: For more up-to-date > + information, including how compiler transformations related to pointer > + comparisons can sometimes cause problems, see > + Documentation/RCU/rcu_dereference.rst. > > An address-dependency barrier is a weaker form of read barrier. In the > case where two loads are performed such that the second depends on the > @@ -561,6 +565,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee: > > ADDRESS-DEPENDENCY BARRIERS (HISTORICAL) > ---------------------------------------- > +[!] This section is marked as HISTORICAL: For more up-to-date information, > +including how compiler transformations related to pointer comparisons can > +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst. > > As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for > DEC Alpha, which means that about the only people who need to pay attention > -- > 2.41.0.585.gd2178a4bd4-goog >
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 06e14efd8662..acc8ec5ce563 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -435,6 +435,11 @@ Memory barriers come in four basic varieties: variables such as READ_ONCE() and rcu_dereference() provide implicit address-dependency barriers. + [!] Note that address dependency barriers can be destroyed by comparison + of a pointer obtained by a marked accessor such as READ_ONCE() or + rcu_dereference() with some value. For an example of this, see + rcu_dereference.rst (part where the comparison of pointers is discussed). + (3) Read (or load) memory barriers. A read barrier is an address-dependency barrier plus a guarantee that all