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: <20140708075902.GM19379@twins.programming.kicks-ass.net>
Date:	Tue, 8 Jul 2014 09:59:02 +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 Mon, Jul 07, 2014 at 03:24:21PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> 
> It is possible to pair acquire and release barriers with other barriers,
> so this commit adds them to the list in the SMP barrier pairing section.
> 
> Reported-by: Lai Jiangshan <laijs@...fujitsu.com>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Reviewed-by: Tejun Heo <tj@...nel.org>


> +A write barrier should always be paired with a data dependency barrier,
> +acquire barrier, release barrier, or read barrier, though a general
> +barrier would also be viable.

   Similarly a read barrier or a data
> +dependency barrier should always be paired with at least a write barrier,
> +an acquire barrier, or a release barrier, though, again, a general
> +barrier is viable:

When I first read the Changelog I though you were going to add things
like:

  An acquire barrier should be paired with a release barrier, however
  .... barrier is also viable.

  A release barrier should be paired with an acquire barrier,... etc.

Now the above does seem to imply such rules but it isn't explicit in
them, since it only lists the requirements for read/write. Now since the
entire thing is indeed symmetric the implications are fairly strong,
still.

Also, it might be good to have a section on the ramifications of pairing
acquire/release with other than themselves, I have the feeling there's
subtle things there.

Content of type "application/pgp-signature" skipped