Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps

[Paul E. McKenney]

On Fri, Oct 20, 2023 at 06:13:34PM +0200, Jonas Oberhauser wrote:
> 
> Am 10/20/2023 um 5:24 PM schrieb Akira Yokosawa:
> > Hi Paul,
> > 
> > On 2023/10/20 22:57, Paul E. McKenney wrote:
> > [...]
> > > So if there are things that rcu_dereference.rst is missing, they do
> > > need to be added.
> > As far as I can see, there is no mention of "address dependency"
> > in rcu_dereference.rst.
> > Yes, I see the discussion in rcu_dereference.rst is all about how
> > not to break address dependency by proper uses of rcu_dereference()
> > and its friends.  But that might not be obvious for readers who
> > followed the references placed in memory-barriers.txt.
> > 
> > Using the term "address dependency" somewhere in rcu_dereference.rst
> > should help such readers, I guess.
> I think that's a good point.

How about the commit shown at the end of this email, with a Reported-by
for both of you?

> > [...]
> > > > Thanks for the response, I started thinking my mails aren't getting through
> > > > again.
> > Jonas, FWIW, your email archived at
> > 
> >      https://lore.kernel.org/linux-doc/1c731fdc-9383-21f2-b2d0-2c879b382687@xxxxxxxxxxxxxxx/
> > 
> > didn't reach my gmail inbox.  I looked for it in the spam folder,
> > but couldn't find it there either.
> > 
> > Your first reply on Oct 6, which is archived at
> > 
> >      https://lore.kernel.org/linux-doc/4110a58a-8db5-57c4-2f5a-e09ee054baaa@xxxxxxxxxxxxxxx/
> > 
> > ended up in my spam folder.
> > 
> > I have no idea why gmail has trouble with your emails so often ...
> > 
> > Anyway, LKML did accept your mails this time.
> > 
> > HTH,
> >          Akira
> 
> 
> Thanks Akira!
> 
> I wrote the gmail support a while ago, but no response.
> 
> Currently no idea who to talk to... Oh well.

Your emails used to end up in my spam folder quite frequently, but
they have been coming through since you changed your email address.

							Thanx, Paul

------------------------------------------------------------------------

commit 982ad36df15d48177d7b1501c8afa0b18ff3c8c9
Author: Paul E. McKenney <paulmck@xxxxxxxxxx>
Date:   Fri Oct 20 10:51:26 2023 -0700

    doc: Mention address and data dependencies in rcu_dereference.rst
    
    This commit adds discussion of address and data dependencies to the
    beginning of rcu_dereference.rst in order to enable readers to more
    easily make the connection to the Linux-kernel memory model in general
    and to memory-barriers.txt in particular.
    
    Reported-by: Jonas Oberhauser <jonas.oberhauser@xxxxxxxxxxxxxxx>
    Reported-by: Akira Yokosawa <akiyks@xxxxxxxxx>
    Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>

diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst
index 3b739f6243c8..659d5913784d 100644
--- a/Documentation/RCU/rcu_dereference.rst
+++ b/Documentation/RCU/rcu_dereference.rst
@@ -3,13 +3,26 @@
 PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()
 ===============================================================
 
-Most of the time, you can use values from rcu_dereference() or one of
-the similar primitives without worries.  Dereferencing (prefix "*"),
-field selection ("->"), assignment ("="), address-of ("&"), addition and
-subtraction of constants, and casts all work quite naturally and safely.
-
-It is nevertheless possible to get into trouble with other operations.
-Follow these rules to keep your RCU code working properly:
+Proper care and feeding of address and data dependencies is critically
+important to correct use of things like RCU.  To this end, the pointers
+returned from the rcu_dereference() family of primitives carry address and
+data dependencies.  These dependencies extend from the rcu_dereference()
+macro's load of the pointer to the later use of that pointer to compute
+either the address of a later memory access (representing an address
+dependency) or the value written by a later memory access (representing
+a data dependency).
+
+Most of the time, these dependencies are preserved, permitting you to
+freely use values from rcu_dereference().  For example, dereferencing
+(prefix "*"), field selection ("->"), assignment ("="), address-of
+("&"), casts, and addition or subtraction of constants all work quite
+naturally and safely.  However, because current compilers do not take
+either address or data dependencies into account it is still possible
+to get into trouble.
+
+Follow these rules to preserve the address and data dependencies emanating
+from your calls to rcu_dereference() and friends, thus keeping your RCU
+readers working properly:
 
 -	You must use one of the rcu_dereference() family of primitives
 	to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU