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]

Message-ID: <20160225140703.GJ3522@linux.vnet.ibm.com>
Date:	Thu, 25 Feb 2016 06:07:03 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 09:21:43AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 24, 2016 at 01:40:13PM -0800, Paul E. McKenney wrote:
> > > > +  (*) 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,
> > > > +      as optimizing compilers do not necessarily respect barrier()
> > > > +      in this case.
> 
> > Let's take the example, replace barrier() with smp_mb(), and see what
> > happens:
> > 
> > 	q = READ_ONCE(a);
> > 	if (q) {
> > 		smp_mb();
> > 		WRITE_ONCE(b, p);
> > 		do_something();
> > 	} else {
> > 		smp_mb();
> > 		WRITE_ONCE(b, p);
> > 		do_something_else();
> > 	}
> 
> Why would an optimizing compiler be allowed to lift _anything_ over a
> barrier() ? Isn't that a bug?
> 
> I thought the whole point of barrier() was to tell the compiler to not
> do such things.

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?

							Thanx, Paul