linux-kernel - Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules

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: <20140716130534.GB19379@twins.programming.kicks-ass.net>
Date:	Wed, 16 Jul 2014 15:05:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
	rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
	dvhart@...ux.intel.com, fweisbec@...il.com, oleg@...hat.com,
	sbw@....edu
Subject: Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release
 barriers to pairing rules

On Wed, Jul 16, 2014 at 05:16:26AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 14, 2014 at 01:57:38PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 08, 2014 at 08:31:17AM -0700, Paul E. McKenney wrote:
> > 
> > > Good point, how about the following?
> > > 
> > > 	General barriers pair with each other, though they also pair
> > > 	with most other types of barriers, albeit without transitivity.
> > 
> > > 	An acquire barrier pairs with a release barrier, but both may also
> > > 	pair with other barriers, including of course general barriers.
> > 
> > > 	A write barrier pairs with a data dependency barrier, an acquire
> > > 	barrier, a release barrier, a read barrier, or a general barrier.
> > 
> > > 	Similarly a read barrier or a data dependency barrier pairs
> > > 	with a write barrier, an acquire barrier, a release barrier,
> > > 	or a general barrier:
> > 
> > It might be clearer with the added whitespace, or as an explicit list  I
> > suppose, but yes.
> 
> If I get ambitious, I might try making a table out of it, but I am not
> yet sure how I would set that up.  Something about having to say a lot
> in each cell, but with only a small amount of room in which to say it.


      |  mb | wmb | rmb | rbd | acq | rel |
 -----+-----+-----+-----+-----+-----+-----+
   mb |  X  |  X  |  X  |  X  |  X  |  X  |
 -----+-----+-----+-----+-----+-----+-----+
  wmb |  X  |     |  X  |  X  |     |     |
 -----+-----+-----+-----+-----+-----+-----+
  rmb |  X  |  X  |     |     |     |     |
 -----+-----+-----+-----+-----+-----+-----+
  rbd |  X  |  X  |     |     |     |     |
 -----+-----+-----+-----+-----+-----+-----+
  acq |  X  |     |     |     |     |  X  |
 -----+-----+-----+-----+-----+-----+-----+
  rel |  X  |     |     |     |  X  |     |
 -----+-----+-----+-----+-----+-----+-----+

(where rbd is read_barrier_depends).

Which is not entirely filled out, in particular I didn't do the creative
acq/rel bits.

> > Ah, I was more thinking of the fact that ACQUIRE/RELEASE are
> > semi-permeable while READ/WRITE are memop dependent.
> > 
> > So any combination will be a semi-permeable memop dependent thing,
> > which is the most narrow barrier possible.
> > 
> > So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier,
> > separated in direction, and READ/WRITE as being 'half' a full barrier
> > separated on type, then the combination is a 'quarter' barrier.
> > 
> > Not arguing they're not useful, just saying we need to be extra careful.
> 
> I do agree completely about the need for extra care!
> 
> For whatever it is worth, the permeability and read-write properties
> are isolated to each barrier in the pair.  For example, with "a" and
> "b" both initially zero:
> 
> 	CPU 1				CPU 2
> 	-----				-----
> 	ACCESS_ONCE(a) = 1;		r1 = b;
> 	smp_store_release(&b, 1);	smp_rmb();
> 	ACCESS_ONCE(c) = 1;		r2 = a;
> 					ACCESS_ONCE(c) = 2;
> 
> The outcome r1==1&&r2==0 is prohibited, but the ordering of the stores
> to "c" are not ordered: CPU 1's smp_store_release() does not affect
> later accesses, and CPU 2's smp_rmb() does not order stores.
> 
> Not sure that it is worth adding this sort of example, though.

Yeah, not sure either. Maybe just a big fat caution if you pair acq/rel
with anything other than its opposite or a general barrier.

Maybe use small 'x' for acq/rel + rmb/wmb and put a caution in the
'legend' for 'x'.

Content of type "application/pgp-signature" skipped