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

Groups > linux.kernel > #1341505 > unrolled thread

[PATCH tip/core/rcu 0/14] Documentation updates for 4.6

Back to article view | Back to linux.kernel

Contents

  [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

Page 2 of 2 — ← Prev page 1 [2]

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

On Thu, Feb 25, 2016 at 03:48:38PM +0100, Peter Zijlstra wrote:
> 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.

The compiler guys would probably argue that the variable "q" is in a
register, so that the "memory" constraint does not apply.  Then the code
movement does not move any actual memory accesses across the "memory"
constraint, and hence they would argue them to be perfectly legal.

That said, I completely agree that this sort of code movement is at
the very least rather unfriendly to concurrent code.  :-/

							Thanx, Paul

[toc] | [prev] | [next] | [standalone]

#1341557 — [PATCH tip/core/rcu 06/14] documentation: Subsequent writes ordered by rcu_dereference()

The current memory-barriers.txt does not address the possibility of
a write to a dereferenced pointer.  This should be rare, but when it
happens, we need that write -not- to be clobbered by the initialization.
This commit therefore adds an example showing a data dependency ordering
a later data-dependent write.

Reported-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 Documentation/memory-barriers.txt | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 6bee0a2c43ab..e9ebeb3b1077 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -555,6 +555,30 @@ between the address load and the data load:
 This enforces the occurrence of one of the two implications, and prevents the
 third possibility from arising.
 
+A data-dependency barrier must also order against dependent writes:
+
+	CPU 1		      CPU 2
+	===============	      ===============
+	{ A == 1, B == 2, C = 3, P == &A, Q == &C }
+	B = 4;
+	<write barrier>
+	WRITE_ONCE(P, &B);
+			      Q = READ_ONCE(P);
+			      <data dependency barrier>
+			      *Q = 5;
+
+The data-dependency barrier must order the read into Q with the store
+into *Q.  This prohibits this outcome:
+
+	(Q == B) && (B == 4)
+
+Please note that this pattern should be rare.  After all, the whole point
+of dependency ordering is to -prevent- writes to the data structure, along
+with the expensive cache misses associated with those writes.  This pattern
+can be used to record rare error conditions and the like, and the ordering
+prevents such records from being lost.
+
+
 [!] Note that this extremely counterintuitive situation arises most easily on
 machines with split caches, so that, for example, one cache bank processes
 even-numbered cache lines and the other bank processes odd-numbered cache
-- 
2.5.2

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web