Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <03ea8aea-2d0c-48ab-bb0d-e585571f1926@gmail.com>
Date:   Sat, 21 Oct 2023 00:24:50 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler
 transformation and address deps
To:     paulmck@kernel.org,
        Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
Cc:     linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-doc@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>,
        Andrea Parri <parri.andrea@gmail.com>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Daniel Lustig <dlustig@nvidia.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Jonathan Corbet <corbet@lwn.net>
References: <ceaeba0a-fc30-4635-802a-668c859a58b2@paulmck-laptop>
 <4110a58a-8db5-57c4-2f5a-e09ee054baaa@huaweicloud.com>
 <1c731fdc-9383-21f2-b2d0-2c879b382687@huaweicloud.com>
 <f363d6e0-5682-43e7-9a3f-6b896c3cd920@paulmck-laptop>
 <b96cfbc1-f6b0-2fa6-b72d-d57c34bbf14b@huaweicloud.com>
 <2694e6e1-3282-4a69-b955-06afd7d7f87f@paulmck-laptop>
Content-Language: en-US
From:   Akira Yokosawa <akiyks@gmail.com>
In-Reply-To: <2694e6e1-3282-4a69-b955-06afd7d7f87f@paulmck-laptop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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