Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1343184

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH tip/core/rcu 0/14] Documentation updates for 4.6 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 01/14] documentation:  Add real-time requirements from CPU-bound workloads "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 14/14] documentation: Clarify compiler store-fusion example "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 12/14] documentation: Document illegality of call_rcu() from offline CPUs "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 07/14] documentation: Distinguish between local and global transitivity "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 05/14] documentation: Remove obsolete reference to RCU-protected indexes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 08/14] documentation:  Add alternative release-acquire outcome "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 11/14] documentation: Transitivity is not cumulativity "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 04/14] documentation: Add synchronize_rcu_mult() to the requirements "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
  [PATCH tip/core/rcu 13/14] documentation: Explain how RCU's combining tree fights contention "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
  [PATCH tip/core/rcu 10/14] documentation: Explain why rcu_read_lock() needs no barrier() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
  [PATCH tip/core/rcu 03/14] documentation: Fix memory-barriers.txt section references "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
  [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
    Re: [PATCH tip/core/rcu 02/14] documentation: Fix control  dependency and identical stores Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 22:20 +0100
      Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 22:50 +0100
        Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores Jianyu Zhan <nasa4836@gmail.com> - 2016-02-25 07:50 +0100
          Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 15:10 +0100
        Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores Peter Zijlstra <peterz@infradead.org> - 2016-02-25 09:30 +0100
          Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 15:10 +0100
            Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores Peter Zijlstra <peterz@infradead.org> - 2016-02-25 15:50 +0100
              Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency  and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 16:50 +0100
  [PATCH tip/core/rcu 06/14] documentation: Subsequent writes ordered by rcu_dereference() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100

csiph-web