linux-kernel - Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores

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:	Thu, 25 Feb 2016 15:48:38 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Lai Jiangshan <jiangshanlai@...il.com>, dipankar@...ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	josh@...htriplett.org, Thomas Gleixner <tglx@...utronix.de>,
	rostedt <rostedt@...dmis.org>,
	David Howells <dhowells@...hat.com>, edumazet@...gle.com,
	dvhart@...ux.intel.com, fweisbec@...il.com,
	Oleg Nesterov <oleg@...hat.com>,
	bobby prani <bobby.prani@...il.com>
Subject: Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency
 and identical stores

On Thu, Feb 25, 2016 at 06:07:03AM -0800, Paul E. McKenney wrote:
> Still bad wording...
> 
> It hasn't actually moved anything over the barrier().  It has instead
> moved both the barrier() and the WRITE_ONCE(b, p) to precede the "if
> (q)".  Mathieu mentioned this over IRC yesterday, and I queue a change
> so that the paragraph now reads as follows:
> 
>   (*) If both legs of the "if" statement begin with identical stores to
>       the same variable, then those stores must be ordered, either by
>       preceding both of them with smp_mb() or by using smp_store_release()
>       to carry out the stores.  Please note that it is -not- sufficient
>       to use barrier() at beginning of each leg of the "if" statement
>       because, as shown by the example above, optimizing compilers can
>       destroy the control dependency while respecting the letter of the
>       barrier() law.
> 
> Does hat help?

Maybe.. I still feel the compiler should not do this; but I'm having a
hard time explaining why.