From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.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>,
Akira Yokosawa <akiyks@gmail.com>,
Daniel Lustig <dlustig@nvidia.com>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH 2/2] docs: memory-barriers: Add note on plain-accesses to address-dependency barriers
Date: Fri, 4 Aug 2023 05:11:27 +0000 [thread overview]
Message-ID: <20230804051127.GA3860381@google.com> (raw)
In-Reply-To: <626d1b48-de6a-4a0b-95d3-3ac438878757@paulmck-laptop>
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
next prev parent reply other threads:[~2023-08-04 5:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 3:24 [PATCH 1/2] docs: rcu: Add cautionary note on plain-accesses to requirements Joel Fernandes (Google)
2023-08-03 3:24 ` [PATCH 2/2] docs: memory-barriers: Add note on plain-accesses to address-dependency barriers Joel Fernandes (Google)
2023-08-03 18:52 ` Paul E. McKenney
2023-08-04 5:11 ` Joel Fernandes [this message]
2023-08-04 13:52 ` Paul E. McKenney
2023-08-04 16:27 ` Joel Fernandes
2023-08-04 18:02 ` Paul E. McKenney
2023-08-03 12:08 ` [PATCH 1/2] docs: rcu: Add cautionary note on plain-accesses to requirements Alan Huang
2023-08-03 12:35 ` Joel Fernandes
2023-08-03 13:36 ` Alan Huang
2023-08-03 16:01 ` Joel Fernandes
2023-08-03 19:25 ` Alan Huang
2023-08-03 23:05 ` Joel Fernandes
2023-08-04 15:47 ` Alan Huang
2023-08-04 16:15 ` Joel Fernandes
2023-08-04 0:01 ` Paul E. McKenney
2023-08-04 12:33 ` Joel Fernandes
2023-08-04 14:00 ` Paul E. McKenney
2023-08-04 16:17 ` Joel Fernandes
2023-08-04 17:02 ` Paul E. McKenney
2023-08-04 16:33 ` Alan Huang
2023-08-04 17:27 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230804051127.GA3860381@google.com \
--to=joel@joelfernandes.org \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.