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:   Mon, 3 Jul 2017 14:07:03 +0100
From:   Will Deacon <will.deacon@....com>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, ldr709@...il.com,
        dhowells@...hat.com, peterz@...radead.org, corbet@....net,
        stern@...land.harvard.edu, parri.andrea@...il.com,
        j.alglave@....ac.uk, luc.maranget@...ia.fr
Subject: Re: [PATCH] doc: Update memory-barriers.txt for read-to-write
 dependencies

Hi Paul,

On Fri, Jun 30, 2017 at 04:28:10PM -0700, Paul E. McKenney wrote:
> The memory-barriers.txt document contains an obsolete passage stating that
> smp_read_barrier_depends() is required to force ordering for read-to-write
> dependencies.  We now know that this is not required, even for DEC Alpha.
> This commit therefore updates this passage to state that read-to-write
> dependencies are respected even without smp_read_barrier_depends().
> 
> Reported-by: Lance Roy <ldr709@...il.com>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Cc: David Howells <dhowells@...hat.com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Alan Stern <stern@...land.harvard.edu>
> Cc: Andrea Parri <parri.andrea@...il.com>
> Cc: Jade Alglave <j.alglave@....ac.uk>
> Cc: Luc Maranget <luc.maranget@...ia.fr>
> 
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 9d5e0f853f08..a8a91b9d5a1b 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -594,7 +594,10 @@ between the address load and the data load:
>  This enforces the occurrence of one of the two implications, and prevents the
>  third possibility from arising.
>  
> -A data-dependency barrier must also order against dependent writes:
> +A data-dependency barrier is not required to order dependent writes
> +because the CPUs that the Linux kernel supports don't do writes until
> +they are certain (1) that the write will actually happen, (2) of the
> +location of the write, and (3) of the value to be written.

Might be worth mentioning that you have to careful with the compiler here,
and pointing to the section on "Control dependencies" so that people don't
just take these three points as guarantees in isolation.

>  
>  	CPU 1		      CPU 2
>  	===============	      ===============
> @@ -603,19 +606,19 @@ A data-dependency barrier must also order against dependent writes:
>  	<write barrier>
>  	WRITE_ONCE(P, &B);
>  			      Q = READ_ONCE(P);
> -			      <data dependency barrier>
>  			      *Q = 5;

Do we want that write to Q to be a WRITE_ONCE? Again, the control
dependencies section does call this out.

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ