[memory-model] 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>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
  

On Thu, Oct 05, 2023 at 09:53:12AM -0700, Paul E. McKenney 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 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>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Andrea Parri <parri.andrea@gmail.com>

Thanks,
  Andrea


> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 06e14efd8662..d414e145f912 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
> @@ -556,6 +560,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, Oct 06, 2023 at 04:24:38PM +0200, Andrea Parri wrote:
> On Thu, Oct 05, 2023 at 09:53:12AM -0700, Paul E. McKenney 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 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>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Reviewed-by: Andrea Parri <parri.andrea@gmail.com>

Thank you, and I will apply on my next rebase.

							Thanx, Paul

> Thanks,
>   Andrea
> 
> 
> > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > index 06e14efd8662..d414e145f912 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
> > @@ -556,6 +560,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
  

Hi Paul,

The "more up-to-date information" makes it sound like (some of) the 
information in this section is out-of-date/no longer valid.

But after reading the sections, it seems the information is valid, but 
discusses mostly the history of address dependency barriers.

Given that the sepcond part  specifically already starts with a 
disclaimer that this information is purely relevant to people interested 
in history or working on alpha, I think it would make more sense to 
modify things slightly differently.

Firstly I'd remove the "historical" part in the first section, and add 
two short paragraphs explaining that

- every marked access implies a address dependency barrier

- address dependencies considered by the model are *semantic* 
dependencies, meaning that a *syntactic* dependency is not sufficient to 
imply ordering; see the rcu file for some examples where compilers can 
elide syntactic dependencies

Secondly, I'd not add the disclaimer to the second section; there's 
already a link to rcu_dereference in that section ( 
https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L634 
), and already a small text explaining that the section is historical.


Best wishes,

jonas


Am 10/5/2023 um 6:53 PM schrieb Paul E. McKenney:
> 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>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 06e14efd8662..d414e145f912 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
> @@ -556,6 +560,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
  

Hi Paul,

on a second thought. Why can't the compiler always do, e.g.,

     int *p = READ_ONCE(shared_ptr);

     assert (*p == 0);

~>

     int *p = READ_ONCE(shared_ptr);

     int val = x; // x is some object that definitely won't segfault, 
but may very well be owned by another thread right now
     if (p != &x) val = *p;

     assert (val == 0);

and in case p == &x, the address dependency is elided


Best wishes,

jonas

Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
> Hi Paul,
>
> The "more up-to-date information" makes it sound like (some of) the 
> information in this section is out-of-date/no longer valid.
>
> But after reading the sections, it seems the information is valid, but 
> discusses mostly the history of address dependency barriers.
>
> Given that the sepcond part  specifically already starts with a 
> disclaimer that this information is purely relevant to people 
> interested in history or working on alpha, I think it would make more 
> sense to modify things slightly differently.
>
> Firstly I'd remove the "historical" part in the first section, and add 
> two short paragraphs explaining that
>
> - every marked access implies a address dependency barrier
>
> - address dependencies considered by the model are *semantic* 
> dependencies, meaning that a *syntactic* dependency is not sufficient 
> to imply ordering; see the rcu file for some examples where compilers 
> can elide syntactic dependencies
>
> Secondly, I'd not add the disclaimer to the second section; there's 
> already a link to rcu_dereference in that section ( 
> https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L634 
> ), and already a small text explaining that the section is historical.
>
>
> Best wishes,
>
> jonas
>
>
> Am 10/5/2023 um 6:53 PM schrieb Paul E. McKenney:
>> 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>
>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>>
>> diff --git a/Documentation/memory-barriers.txt 
>> b/Documentation/memory-barriers.txt
>> index 06e14efd8662..d414e145f912 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
>> @@ -556,6 +560,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 Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
> Hi Paul,
> 
> on a second thought. Why can't the compiler always do, e.g.,
> 
>     int *p = READ_ONCE(shared_ptr);
> 
>     assert (*p == 0);
> 
> ~>
> 
>     int *p = READ_ONCE(shared_ptr);
> 
>     int val = x; // x is some object that definitely won't segfault, but may
> very well be owned by another thread right now
>     if (p != &x) val = *p;

The compiler is forbidden from inventing pointer comparisons.

>     assert (val == 0);
> 
> and in case p == &x, the address dependency is elided

But yes, this is one reason why Documentation/RCU/rcu_dereference.rst
warns about pointer comparisons.

> Best wishes,
> 
> jonas
> 
> Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
> > Hi Paul,
> > 
> > The "more up-to-date information" makes it sound like (some of) the
> > information in this section is out-of-date/no longer valid.

The old smp_read_barrier_depends() that these section cover really
does no longer exist.

> > But after reading the sections, it seems the information is valid, but
> > discusses mostly the history of address dependency barriers.
> > 
> > Given that the sepcond part  specifically already starts with a
> > disclaimer that this information is purely relevant to people interested
> > in history or working on alpha, I think it would make more sense to
> > modify things slightly differently.
> > 
> > Firstly I'd remove the "historical" part in the first section, and add
> > two short paragraphs explaining that
> > 
> > - every marked access implies a address dependency barrier

This is covered in rcu_dereference.rst.  Or is something missing there?
Please note that the atomic_read() primitives operate on integers
rather than pointers, so are off the table.  Yes, in theory, some of
the value-returning atomic read-modify-write operations could head a
dependency chain, but these things are sufficiently heavyweight that
most situations would be better served by an _acquire() suffix than by
a relaxed version of such an atomic operation.

> > - address dependencies considered by the model are *semantic*
> > dependencies, meaning that a *syntactic* dependency is not sufficient to
> > imply ordering; see the rcu file for some examples where compilers can
> > elide syntactic dependencies

There is a bunch of text in rcu_dereference.rst to this effect.  Or
is there some aspect that is missing from that document?

The longer-term direction, perhaps a few years from now, is for the
first section to simply reference rcu_dereference.rst and for the second
section to be removed completely.

> > Secondly, I'd not add the disclaimer to the second section; there's
> > already a link to rcu_dereference in that section ( https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L634
> > ), and already a small text explaining that the section is historical.

The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense.  ;-)

But I very much appreciate your review and feedback, and I also apologize
for my slowness.

							Thanx, Paul

> > Best wishes,
> > 
> > jonas
> > 
> > 
> > Am 10/5/2023 um 6:53 PM schrieb Paul E. McKenney:
> > > 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>
> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > > 
> > > diff --git a/Documentation/memory-barriers.txt
> > > b/Documentation/memory-barriers.txt
> > > index 06e14efd8662..d414e145f912 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
> > > @@ -556,6 +560,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
>
  

Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
> On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
>> Hi Paul,
>> [...]
> The compiler is forbidden from inventing pointer comparisons.

TIL :) Btw, do you remember a discussion where this is clarified? A 
quick search didn't turn up anything.


>> Best wishes,
>>
>> jonas
>>
>> Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
>>> Hi Paul,
>>>
>>> The "more up-to-date information" makes it sound like (some of) the
>>> information in this section is out-of-date/no longer valid.
> The old smp_read_barrier_depends() that these section cover really
> does no longer exist.


You mean that they *intend to* cover? smp_read_barrier_depends never 
appears in the text, so anyone reading this section without prior 
knowledge has no way of realizing that this is what the sections are 
talking about.

On the other hand the implicit address dependency barriers that do exist 
are mentioned in the text. And that part is still true.


>
>>> But after reading the sections, it seems the information is valid, but
>>> discusses mostly the history of address dependency barriers.
>>>
>>> Given that the sepcond part  specifically already starts with a
>>> disclaimer that this information is purely relevant to people interested
>>> in history or working on alpha, I think it would make more sense to
>>> modify things slightly differently.
>>>
>>> Firstly I'd remove the "historical" part in the first section, and add
>>> two short paragraphs explaining that
>>>
>>> - every marked access implies a address dependency barrier
> This is covered in rcu_dereference.rst.

Let me quote a much wiser man than myself here: "

The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense.  ;-)

"

The main reason I would like to add this here at the very top is that

- this section serves to frigthen children about the dangers of address 
dependencies,

- never mentions a way to add them - I need to happen to read another 
section of the manual to find that out

- and says this information is historical without specifying which parts 
are still relevant

(and the parts that are still there are all still relevant, while the 
parts that only the authors know was intended to be there and is 
out-of-date is already gone).

So I would add a disclaimer specifying that (since 4.15) *all* marked 
accesses imply read dependency barriers which resolve most of the issues 
mentioned in the remainder of the article.
However, some issues remain because the dependencies that are preserved 
by such barriers are just *semantic* dependencies, and readers should 
check rcu_dereference.rst for examples of what that implies.


> [...]
> most situations would be better served by an _acquire() suffix than by
> a relaxed version of [...] an atomic [...]


I completely agree. I even considered removing address dependencies 
altogether from the company-internal memory models.
But people sometimes get a little bit angry and start asking many questions.
The valuable time of the model maintainer should be considered when 
designing memory models.


>
>>> - address dependencies considered by the model are *semantic*
>>> dependencies, meaning that a *syntactic* dependency is not sufficient to
>>> imply ordering; see the rcu file for some examples where compilers can
>>> elide syntactic dependencies
> There is a bunch of text in rcu_dereference.rst to this effect.  Or
> is there some aspect that is missing from that document?


That's what I meant by "see the rcu file" --- include a link to 
rcu_dereference.rst in that paragraph.
So that people know to check out rcu_dereference.rst for more 
explanations to this effect.


> The longer-term direction, perhaps a few years from now, is for the
> first section to simply reference rcu_dereference.rst and for the second
> section to be removed completely.


Sounds good to me, but that doesn't mean we need to compromise the 
readability in the interim :)


>
> [...]
> The problem is that people insist on diving into the middle of documents,
> so sometimes repetition is a necessary form of self defense.  ;-)
>
> But I very much appreciate your review and feedback, and I also apologize
> for my slowness.
>
> 							Thanx, Paul
>

Thanks for the response, I started thinking my mails aren't getting 
through again.

Have fun,

jonas
  

On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
> 
> Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
> > On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
> > > Hi Paul,
> > > [...]
> > The compiler is forbidden from inventing pointer comparisons.
> 
> TIL :) Btw, do you remember a discussion where this is clarified? A quick
> search didn't turn up anything.

This was a verbal discussion with Richard Smith at the 2020 C++ Standards
Committee meeting in Prague.  I honestly do not know what standardese
supports this.

> > > Best wishes,
> > > 
> > > jonas
> > > 
> > > Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
> > > > Hi Paul,
> > > > 
> > > > The "more up-to-date information" makes it sound like (some of) the
> > > > information in this section is out-of-date/no longer valid.
> > The old smp_read_barrier_depends() that these section cover really
> > does no longer exist.
> 
> You mean that they *intend to* cover? smp_read_barrier_depends never appears
> in the text, so anyone reading this section without prior knowledge has no
> way of realizing that this is what the sections are talking about.

It also doesn't appear in the kernel anymore.

> On the other hand the implicit address dependency barriers that do exist are
> mentioned in the text. And that part is still true.

And this relevant discussion is moving to rcu_dereference.rst, and the
current text is just for people who read memory-barriers.txt some time
back and are expecting to find the same information in the same place.

So if there are things that rcu_dereference.rst is missing, they do
need to be added.

> > > > But after reading the sections, it seems the information is valid, but
> > > > discusses mostly the history of address dependency barriers.
> > > > 
> > > > Given that the sepcond part  specifically already starts with a
> > > > disclaimer that this information is purely relevant to people interested
> > > > in history or working on alpha, I think it would make more sense to
> > > > modify things slightly differently.
> > > > 
> > > > Firstly I'd remove the "historical" part in the first section, and add
> > > > two short paragraphs explaining that
> > > > 
> > > > - every marked access implies a address dependency barrier
> > This is covered in rcu_dereference.rst.
> 
> Let me quote a much wiser man than myself here: "
> 
> The problem is that people insist on diving into the middle of documents,
> so sometimes repetition is a necessary form of self defense.  ;-)
> 
> "

;-) ;-) ;-)

> The main reason I would like to add this here at the very top is that
> 
> - this section serves to frigthen children about the dangers of address
> dependencies,
> 
> - never mentions a way to add them - I need to happen to read another
> section of the manual to find that out

Both are now the job of rcu_dereference.rst.

> - and says this information is historical without specifying which parts are
> still relevant

Readers not interested in history should just go to rcu_dereference.rst,
and if pieces are missing from rcu_dereference.rst, they should be
added there.  (Except of course not the historical points that are not
relevant to the current kernel.)

> (and the parts that are still there are all still relevant, while the parts
> that only the authors know was intended to be there and is out-of-date is
> already gone).

The question is instead what parts that are still relevant are missing
from rcu_dereference.rst.

> So I would add a disclaimer specifying that (since 4.15) *all* marked
> accesses imply read dependency barriers which resolve most of the issues
> mentioned in the remainder of the article.
> However, some issues remain because the dependencies that are preserved by
> such barriers are just *semantic* dependencies, and readers should check
> rcu_dereference.rst for examples of what that implies.

Or maybe it is now time to remove those sections from memory-barriers.txt,
leaving only the first section's pointer to rcu_dereference.rst.
It still feels a bit early to me, and I am still trying to figure out
why you care so much about these sections.  ;-)

> > [...]
> > most situations would be better served by an _acquire() suffix than by
> > a relaxed version of [...] an atomic [...]
> 
> I completely agree. I even considered removing address dependencies
> altogether from the company-internal memory models.
> But people sometimes get a little bit angry and start asking many questions.
> The valuable time of the model maintainer should be considered when
> designing memory models.

Yeah, that is always a tough tradeoff, to be sure!

> > > > - address dependencies considered by the model are *semantic*
> > > > dependencies, meaning that a *syntactic* dependency is not sufficient to
> > > > imply ordering; see the rcu file for some examples where compilers can
> > > > elide syntactic dependencies
> > There is a bunch of text in rcu_dereference.rst to this effect.  Or
> > is there some aspect that is missing from that document?
> 
> That's what I meant by "see the rcu file" --- include a link to
> rcu_dereference.rst in that paragraph.
> So that people know to check out rcu_dereference.rst for more explanations
> to this effect.

You mean this paragraph?

 (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.

If so, that last line is intended to be the required link.

Or am I looking in the wrong place?

> > The longer-term direction, perhaps a few years from now, is for the
> > first section to simply reference rcu_dereference.rst and for the second
> > section to be removed completely.
> 
> Sounds good to me, but that doesn't mean we need to compromise the
> readability in the interim :)

Some compromise is needed for people that read the document some time
back and are looking for something specific.

> > [...]
> > The problem is that people insist on diving into the middle of documents,
> > so sometimes repetition is a necessary form of self defense.  ;-)
> > 
> > But I very much appreciate your review and feedback, and I also apologize
> > for my slowness.
> 
> Thanks for the response, I started thinking my mails aren't getting through
> again.

Again, apologies!

							Thanx, Paul
  

Hi Paul,

On 2023/10/20 22:57, Paul E. McKenney wrote:
> On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
>>
>> Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
>>> On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
[...]
>>>> Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
>>>>> Hi Paul,
>>>>>
>>>>> The "more up-to-date information" makes it sound like (some of) the
>>>>> information in this section is out-of-date/no longer valid.
>>> The old smp_read_barrier_depends() that these section cover really
>>> does no longer exist.
>>
>> You mean that they *intend to* cover? smp_read_barrier_depends never appears
>> in the text, so anyone reading this section without prior knowledge has no
>> way of realizing that this is what the sections are talking about.
> 
> It also doesn't appear in the kernel anymore.
> 
>> On the other hand the implicit address dependency barriers that do exist are
>> mentioned in the text. And that part is still true.
> 
> And this relevant discussion is moving to rcu_dereference.rst, and the
> current text is just for people who read memory-barriers.txt some time
> back and are expecting to find the same information in the same place.
> 
> 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.

[...]
>>
>> 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@huaweicloud.com/

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@huaweicloud.com/

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
  

Am 10/20/2023 um 3:57 PM schrieb Paul E. McKenney:
> On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
>> Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
>>> On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
>>>> Hi Paul,
>>>> [...]
>>> The compiler is forbidden from inventing pointer comparisons.
>> TIL :) Btw, do you remember a discussion where this is clarified? A quick
>> search didn't turn up anything.
> This was a verbal discussion with Richard Smith at the 2020 C++ Standards
> Committee meeting in Prague.  I honestly do not know what standardese
> supports this.


Then this e-mail thread shall be my evidence for future discussion.


>
>>>> Best wishes,
>>>>
>>>> jonas
>>>>
>>>> Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
>>>>> Hi Paul,
>>>>>
>>>>> The "more up-to-date information" makes it sound like (some of) the
>>>>> information in this section is out-of-date/no longer valid.
>>> The old smp_read_barrier_depends() that these section cover really
>>> does no longer exist.
>>
>> (and the parts that are still there are all still relevant, while the parts
>> that only the authors know was intended to be there and is out-of-date is
>> already gone).
> The question is instead what parts that are still relevant are missing
> from rcu_dereference.rst.
>
>> So I would add a disclaimer specifying that (since 4.15) *all* marked
>> accesses imply read dependency barriers which resolve most of the issues
>> mentioned in the remainder of the article.
>> However, some issues remain because the dependencies that are preserved by
>> such barriers are just *semantic* dependencies, and readers should check
>> rcu_dereference.rst for examples of what that implies.
> Or maybe it is now time to remove those sections from memory-barriers.txt,
> leaving only the first section's pointer to rcu_dereference.rst.


That would also make sense to me.


> It still feels a bit early to me, and I am still trying to figure out
> why you care so much about these sections.  ;-)


I honestly don't care about the sections themselves, but I do care about 
1) address dependency ordering and 2) not confusing people more than 
necessary.
IMHO the sections right now are more confusing than necessary.
As I said before, I think they should clarify what exactly is historical 
in a short sentence. E.g.

  (2) Address-dependency barriers (historical).
      [!] This section is marked as HISTORICAL: it covers the obsolete barrier
      smp_read_barrier_depends(), the semantics of which is now implicit in all
      marked accesses. For more up-to-date information, including how compiler
      transformations related to pointer comparisons can sometimes cause problems,
      see Documentation/RCU/rcu_dereference.rst.

I think this tiny rewrite makes it much more clear. Specifically it tells *why* the text is historical (and why we maybe don't need to read it anymore).

Btw, when I raised my concerns about what should be there I didn't mean to imply those points are missing, just trying to sketch what the paragraph should look like in my opinion.
The paragraphs you are adding already had several of those points.


>>> The longer-term direction, perhaps a few years from now, is for the
>>> first section to simply reference rcu_dereference.rst and for the second
>>> section to be removed completely.
>> Sounds good to me, but that doesn't mean we need to compromise the
>> readability in the interim :)
> Some compromise is needed for people that read the document some time
> back and are looking for something specific.

Yes. But the compromise should be "there's a blob of text other people 
don't need to read", not "there's a blob of text that will leave other 
people confused".


Best wishes,

jonas
  

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.


>
> [...]
>>> 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@huaweicloud.com/
>
> 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@huaweicloud.com/
>
> 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.
  

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@huaweicloud.com/
> > 
> > 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@huaweicloud.com/
> > 
> > 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@kernel.org>
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@huaweicloud.com>
    Reported-by: Akira Yokosawa <akiyks@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

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
  

On Fri, Oct 20, 2023 at 06:00:19PM +0200, Jonas Oberhauser wrote:
> 
> Am 10/20/2023 um 3:57 PM schrieb Paul E. McKenney:
> > On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
> > > Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
> > > > On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
> > > > > Hi Paul,
> > > > > [...]
> > > > The compiler is forbidden from inventing pointer comparisons.
> > > TIL :) Btw, do you remember a discussion where this is clarified? A quick
> > > search didn't turn up anything.
> > This was a verbal discussion with Richard Smith at the 2020 C++ Standards
> > Committee meeting in Prague.  I honestly do not know what standardese
> > supports this.
> 
> Then this e-mail thread shall be my evidence for future discussion.

I am sure that Richard will be delighted, especially given that he
did not seem at all happy with this don't-invent-pointer-comparisons
rule.  ;-)

> > > > > Best wishes,
> > > > > 
> > > > > jonas
> > > > > 
> > > > > Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
> > > > > > Hi Paul,
> > > > > > 
> > > > > > The "more up-to-date information" makes it sound like (some of) the
> > > > > > information in this section is out-of-date/no longer valid.
> > > > The old smp_read_barrier_depends() that these section cover really
> > > > does no longer exist.
> > > 
> > > (and the parts that are still there are all still relevant, while the parts
> > > that only the authors know was intended to be there and is out-of-date is
> > > already gone).
> > The question is instead what parts that are still relevant are missing
> > from rcu_dereference.rst.
> > 
> > > So I would add a disclaimer specifying that (since 4.15) *all* marked
> > > accesses imply read dependency barriers which resolve most of the issues
> > > mentioned in the remainder of the article.
> > > However, some issues remain because the dependencies that are preserved by
> > > such barriers are just *semantic* dependencies, and readers should check
> > > rcu_dereference.rst for examples of what that implies.
> > Or maybe it is now time to remove those sections from memory-barriers.txt,
> > leaving only the first section's pointer to rcu_dereference.rst.
> 
> That would also make sense to me.
> 
> > It still feels a bit early to me, and I am still trying to figure out
> > why you care so much about these sections.  ;-)
> 
> I honestly don't care about the sections themselves, but I do care about 1)
> address dependency ordering and 2) not confusing people more than necessary.
> IMHO the sections right now are more confusing than necessary.
> As I said before, I think they should clarify what exactly is historical in
> a short sentence. E.g.
> 
>  (2) Address-dependency barriers (historical).
>      [!] This section is marked as HISTORICAL: it covers the obsolete barrier
>      smp_read_barrier_depends(), the semantics of which is now implicit in all
>      marked accesses. For more up-to-date information, including how compiler
>      transformations related to pointer comparisons can sometimes cause problems,
>      see Documentation/RCU/rcu_dereference.rst.
> 
> I think this tiny rewrite makes it much more clear. Specifically it tells *why* the text is historical (and why we maybe don't need to read it anymore).

Good point!  I reworked this a bit and added it to both HISTORICAL
sections, with your Suggested-by.

> Btw, when I raised my concerns about what should be there I didn't mean to imply those points are missing, just trying to sketch what the paragraph should look like in my opinion.
> The paragraphs you are adding already had several of those points.

Very good, but I did have to ask.  It wouldn't be the first time that
I left something out.  ;-)

> > > > The longer-term direction, perhaps a few years from now, is for the
> > > > first section to simply reference rcu_dereference.rst and for the second
> > > > section to be removed completely.
> > > Sounds good to me, but that doesn't mean we need to compromise the
> > > readability in the interim :)
> > Some compromise is needed for people that read the document some time
> > back and are looking for something specific.
> 
> Yes. But the compromise should be "there's a blob of text other people don't
> need to read", not "there's a blob of text that will leave other people
> confused".

Fair enough in general, but I cannot promise to never confuse people.
This is after all memory ordering.  And different people will be confused
by different things.

But I do very much like your suggested clarification.  Please let me
know if I messed anything up in the translation.

							Thanx, Paul

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

commit 566c71eee55b26ece5855ebbee6f8762495d78f7
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Fri Oct 20 11:04:27 2023 -0700

    doc: Clarify historical disclaimers in memory-barriers.txt
    
    This commit makes it clear that the reason that these sections are
    historical is that smp_read_barrier_depends() is no more.  It also
    removes the point about comparison operations, given that there are
    other optimizations that can break address dependencies.
    
    Suggested-by: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Andrea Parri <parri.andrea@gmail.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Jade Alglave <j.alglave@ucl.ac.uk>
    Cc: Luc Maranget <luc.maranget@inria.fr>
    Cc: Akira Yokosawa <akiyks@gmail.com>
    Cc: Daniel Lustig <dlustig@nvidia.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: <linux-arch@vger.kernel.org>
    Cc: <linux-doc@vger.kernel.org>

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index d414e145f912..4202174a6262 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -396,10 +396,11 @@ 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.
+     [!] This section is marked as HISTORICAL: it covers the long-obsolete
+     smp_read_barrier_depends() macro, the semantics of which are now
+     implicit in all marked accesses.  For more up-to-date information,
+     including how compiler transformations can sometimes break address
+     dependencies, 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
@@ -560,9 +561,11 @@ 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.
+[!] This section is marked as HISTORICAL: it covers the long-obsolete
+smp_read_barrier_depends() macro, the semantics of which are now implicit
+in all marked accesses.  For more up-to-date information, including
+how compiler transformations can sometimes break address dependencies,
+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
  

Am 10/20/2023 um 8:13 PM schrieb Paul E. McKenney:
> On Fri, Oct 20, 2023 at 06:00:19PM +0200, Jonas Oberhauser wrote:
>> Am 10/20/2023 um 3:57 PM schrieb Paul E. McKenney:
>>> On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
>>>> Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
>>>>> On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
>>>>>> Hi Paul,
>>>>>> [...]
>>>>> The compiler is forbidden from inventing pointer comparisons.
>>>> TIL :) Btw, do you remember a discussion where this is clarified? A quick
>>>> search didn't turn up anything.
>>> This was a verbal discussion with Richard Smith at the 2020 C++ Standards
>>> Committee meeting in Prague.  I honestly do not know what standardese
>>> supports this.
>> Richard Smith
>> Then this e-mail thread shall be my evidence for future discussion.
> I am sure that Richard will be delighted, especially given that he
> did not seem at all happy with this don't-invent-pointer-comparisons
> rule.  ;-)


Neither am I :D
He can voice his delightenment or lack thereof to me if we ever happen 
to meet in person.


>> I think this tiny rewrite makes it much more clear. Specifically it tells *why* the text is historical (and why we maybe don't need to read it anymore).
> Good point!  I reworked this a bit and added it to both HISTORICAL
> sections, with your Suggested-by.


The new version looks good to me!


>>>>> The longer-term direction, perhaps a few years from now, is for the
>>>>> first section to simply reference rcu_dereference.rst and for the second
>>>>> section to be removed completely.
>>>> Sounds good to me, but that doesn't mean we need to compromise the
>>>> readability in the interim :)
>>> Some compromise is needed for people that read the document some time
>>> back and are looking for something specific.
>> Yes. But the compromise should be "there's a blob of text other people don't
>> need to read", not "there's a blob of text that will leave other people
>> confused".
> Fair enough in general, but I cannot promise to never confuse people.
> This is after all memory ordering.  And different people will be confused
> by different things.


You can say that twice. In fact I suspect this is not the first time you 
say that :))

   jonas
  

Am 10/20/2023 um 7:56 PM schrieb 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,


I think it's very clear.


> with a Reported-by for both of you?

I haven't reported anything.


>>> [...]
>>>>> 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@huaweicloud.com/
>>>
>>> didn't reach my gmail inbox.  I looked for it in the spam folder,
>>> but couldn't find it there either.
>>> [...]
>>
>> 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.


In return, I receive all mail from the mailing list, if is also 
addressed to me, twice.
So it evens out, somehow? (I suspect this is a configuration error in my 
mail filters on my side though)

Have a lot of fun,

     jonas
  

On Sat, Oct 21, 2023 at 03:36:21PM +0200, Jonas Oberhauser wrote:
> 
> Am 10/20/2023 um 8:13 PM schrieb Paul E. McKenney:
> > On Fri, Oct 20, 2023 at 06:00:19PM +0200, Jonas Oberhauser wrote:
> > > Am 10/20/2023 um 3:57 PM schrieb Paul E. McKenney:
> > > > On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
> > > > > Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
> > > > > > On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
> > > > > > > Hi Paul,
> > > > > > > [...]
> > > > > > The compiler is forbidden from inventing pointer comparisons.
> > > > > TIL :) Btw, do you remember a discussion where this is clarified? A quick
> > > > > search didn't turn up anything.
> > > > This was a verbal discussion with Richard Smith at the 2020 C++ Standards
> > > > Committee meeting in Prague.  I honestly do not know what standardese
> > > > supports this.
> > > Richard Smith
> > > Then this e-mail thread shall be my evidence for future discussion.
> > I am sure that Richard will be delighted, especially given that he
> > did not seem at all happy with this don't-invent-pointer-comparisons
> > rule.  ;-)
> 
> Neither am I :D

Why do you want to invent pointer comparisons?

From a practical standpoint, one big problem with them is that they
make it quite hard to write certain types of software, including device
drivers, memory allocators, things like memset(), and so on.

> He can voice his delightenment or lack thereof to me if we ever happen to
> meet in person.

More likely to me, but I will happily pass it on.

> > > I think this tiny rewrite makes it much more clear. Specifically it tells *why* the text is historical (and why we maybe don't need to read it anymore).
> > Good point!  I reworked this a bit and added it to both HISTORICAL
> > sections, with your Suggested-by.
> 
> The new version looks good to me!
> 
> > > > > > The longer-term direction, perhaps a few years from now, is for the
> > > > > > first section to simply reference rcu_dereference.rst and for the second
> > > > > > section to be removed completely.
> > > > > Sounds good to me, but that doesn't mean we need to compromise the
> > > > > readability in the interim :)
> > > > Some compromise is needed for people that read the document some time
> > > > back and are looking for something specific.
> > > Yes. But the compromise should be "there's a blob of text other people don't
> > > need to read", not "there's a blob of text that will leave other people
> > > confused".
> > Fair enough in general, but I cannot promise to never confuse people.
> > This is after all memory ordering.  And different people will be confused
> > by different things.
> 
> You can say that twice. In fact I suspect this is not the first time you say
> that :))

Easy for me to say, "that that that that that that that that that that"!

							Thanx, Paul
  

On Sat, Oct 21, 2023 at 03:45:16PM +0200, Jonas Oberhauser wrote:
> 
> Am 10/20/2023 um 7:56 PM schrieb 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,
> 
> I think it's very clear.

Thank you for looking it over!

> > with a Reported-by for both of you?
> 
> I haven't reported anything.

I doubt that Akira would have said anything had you not initiated this
discussion.  But if you would like, I can remove your Reported-by,
though I would need you to explicitly ask.

> > > > [...]
> > > > > > 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@huaweicloud.com/
> > > > 
> > > > didn't reach my gmail inbox.  I looked for it in the spam folder,
> > > > but couldn't find it there either.
> > > > [...]
> > > 
> > > 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.
> 
> In return, I receive all mail from the mailing list, if is also addressed to
> me, twice.
> So it evens out, somehow? (I suspect this is a configuration error in my
> mail filters on my side though)

Too much fun!

							Thanx, Paul
  

On Sat, Oct 21, 2023 at 08:10:27AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 21, 2023 at 03:36:21PM +0200, Jonas Oberhauser wrote:
> > 
> > Am 10/20/2023 um 8:13 PM schrieb Paul E. McKenney:
> > > Fair enough in general, but I cannot promise to never confuse people.
> > > This is after all memory ordering.  And different people will be confused
> > > by different things.
> > 
> > You can say that twice. In fact I suspect this is not the first time you say
> > that :))
> 
> Easy for me to say, "that that that that that that that that that that"!

This reminds me of a sentence I once heard as an example of 
inscrutability.  Written without punctuation, it goes:

	Jack when Joe had had had had had had had had had had
	the teachers approval.

Properly punctuated, it says:

	Jack, when Joe had had "had", had had "had had"; "had had" had 
	the teacher's approval.

The context is supposed to be a comparison of the words two students 
used in their essays and how their teacher reacted.  It actually 
makes sense when read carefully.

Alan
  

On Sat, Oct 21, 2023 at 12:03:30PM -0400, Alan Stern wrote:
> On Sat, Oct 21, 2023 at 08:10:27AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 21, 2023 at 03:36:21PM +0200, Jonas Oberhauser wrote:
> > > 
> > > Am 10/20/2023 um 8:13 PM schrieb Paul E. McKenney:
> > > > Fair enough in general, but I cannot promise to never confuse people.
> > > > This is after all memory ordering.  And different people will be confused
> > > > by different things.
> > > 
> > > You can say that twice. In fact I suspect this is not the first time you say
> > > that :))
> > 
> > Easy for me to say, "that that that that that that that that that that"!
> 
> This reminds me of a sentence I once heard as an example of 
> inscrutability.  Written without punctuation, it goes:
> 
> 	Jack when Joe had had had had had had had had had had
> 	the teachers approval.
> 
> Properly punctuated, it says:
> 
> 	Jack, when Joe had had "had", had had "had had"; "had had" had 
> 	the teacher's approval.
> 
> The context is supposed to be a comparison of the words two students 
> used in their essays and how their teacher reacted.  It actually 
> makes sense when read carefully.

Cute!

In contrast, any sensible interpretationof my string of "that"s is
pure coincidence.  ;-)

							Thanx, Paul