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]
Message-ID: <4110a58a-8db5-57c4-2f5a-e09ee054baaa@huaweicloud.com>
Date:   Fri, 6 Oct 2023 18:39:18 +0200
From:   Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To:     paulmck@...nel.org, linux-kernel@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-doc@...r.kernel.org
Cc:     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

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.

But after reading the sections, it seems the information is valid, but 
discusses mostly the history of address dependency barriers.

Given that the sepcond part  specifically already starts with a 
disclaimer that this information is purely relevant to people interested 
in history or working on alpha, I think it would make more sense to 
modify things slightly differently.

Firstly I'd remove the "historical" part in the first section, and add 
two short paragraphs explaining that

- every marked access implies a address dependency barrier

- address dependencies considered by the model are *semantic* 
dependencies, meaning that a *syntactic* dependency is not sufficient to 
imply ordering; see the rcu file for some examples where compilers can 
elide syntactic dependencies

Secondly, I'd not add the disclaimer to the second section; there's 
already a link to rcu_dereference in that section ( 
https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L634 
), and already a small text explaining that the section is historical.


Best wishes,

jonas


Am 10/5/2023 um 6:53 PM schrieb Paul E. McKenney:
> The compiler has the ability to cause misordering by destroying
> address-dependency barriers if comparison operations are used. Add a
> note about this to memory-barriers.txt in the beginning of both the
> historical address-dependency sections and point to rcu-dereference.rst
> for more information.
>
> Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 06e14efd8662..d414e145f912 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties:
>   
>   
>    (2) Address-dependency barriers (historical).
> +     [!] This section is marked as HISTORICAL: For more up-to-date
> +     information, including how compiler transformations related to pointer
> +     comparisons can sometimes cause problems, see
> +     Documentation/RCU/rcu_dereference.rst.
>   
>        An address-dependency barrier is a weaker form of read barrier.  In the
>        case where two loads are performed such that the second depends on the
> @@ -556,6 +560,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
>   
>   ADDRESS-DEPENDENCY BARRIERS (HISTORICAL)
>   ----------------------------------------
> +[!] This section is marked as HISTORICAL: For more up-to-date information,
> +including how compiler transformations related to pointer comparisons can
> +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst.
>   
>   As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
>   DEC Alpha, which means that about the only people who need to pay attention

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ