Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps
From: Akira Yokosawa
Date: Fri Oct 20 2023 - 11:25:02 EST
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@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