linux-kernel - Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier

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, 4 Dec 2017 14:15:01 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org,
        mingo@...nel.org, jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
        edumazet@...gle.com, fweisbec@...il.com, oleg@...hat.com
Subject: Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies
 smp_barrier_depends()

On Mon, Dec 04, 2017 at 10:54:48PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 04, 2017 at 10:52:15AM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 04, 2017 at 03:38:56PM +0000, David Howells wrote:
> > > Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > > 
> > > > -	Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
> > > > +	Q = READ_ONCE(P); D = READ_ONCE(*Q);
> > > >  
> > > >       the CPU will issue the following memory operations:
> > > >  
> > > >  	Q = LOAD P, D = LOAD *Q
> > > 
> > > The CPU may now issue two barriers in addition to the loads, so should we show
> > > this?  E.g.:
> > > 
> > > 	Q = LOAD P, BARRIER, D = LOAD *Q, BARRIER
> > 
> > Good point!  How about as shown in the updated patch below?
> 
> Humm, I thought the idea was to completely remove read_barrier_depends
> from the lkmm and memory-barriers.txt, making it an Alpha implementation
> detail.

That was indeed my hope, but a too-abrupt departure of DEC Alpha seemed
to be causing some confusion, so I jumped on David's suggested change.  My
hope now is to slowly remove mention of DEC Alpha from the documentation.

Hmmm...  Maybe we need an LWN article on how we are weaning the memory
model from its historical DEC Alpha influences?  That might get the word
out more effectively.

							Thanx, Paul