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


Groups > linux.kernel > #1342962

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

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores
Date 2016-02-25 09:30 +0100
Message-ID <r5Zt8-120-19@gated-at.bofh.it> (permalink)
References <r5zS2-84d-11@gated-at.bofh.it> <r5A1J-87D-37@gated-at.bofh.it> <r5P0K-1T4-9@gated-at.bofh.it> <r5PtM-2bk-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

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