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

[Akira Yokosawa <akiyks@gmail.com>]

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