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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 21 Oct 2023 00:24:50 +0900
From:   Akira Yokosawa <akiyks@...il.com>
To:     paulmck@...nel.org,
        Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-doc@...r.kernel.org, Alan Stern <stern@...land.harvard.edu>,
        Andrea Parri <parri.andrea@...il.com>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Daniel Lustig <dlustig@...dia.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler
 transformation and address deps

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