Date:   Fri, 20 Oct 2023 18:00:19 +0200
From:   Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To:     paulmck@...nel.org
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>,
        Akira Yokosawa <akiyks@...il.com>,
        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


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

Powered by blists - more mailing lists