Messages in this thread | | | Date | Fri, 8 Jun 2018 02:38:26 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] doc: Update synchronize_rcu() definition in whatisRCU.txt |
| |
On Thu, Jun 07, 2018 at 12:01:57PM +0200, Andrea Parri wrote: > The synchronize_rcu() definition based on RW-locks in whatisRCU.txt > does not meet the "Memory-Barrier Guarantees" in Requirements.html; > for example, the following SB-like test: > > P0: P1: > > WRITE_ONCE(x, 1); WRITE_ONCE(y, 1); > synchronize_rcu(); smp_mb(); > r0 = READ_ONCE(y); r1 = READ_ONCE(x); > > should not be allowed to reach the state "r0 = 0 AND r1 = 0", but > the current write_lock()+write_unlock() definition can not ensure > this. Remedies this by inserting an smp_mb__after_spinlock(). > > Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Queued for review, thank you!
Thanx, Paul
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Cc: Josh Triplett <josh@joshtriplett.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > Cc: Lai Jiangshan <jiangshanlai@gmail.com> > Cc: Jonathan Corbet <corbet@lwn.net> > --- > Documentation/RCU/whatisRCU.txt | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt > index a27fbfb0efb82..86a54ff911fc2 100644 > --- a/Documentation/RCU/whatisRCU.txt > +++ b/Documentation/RCU/whatisRCU.txt > @@ -586,6 +586,7 @@ It is extremely simple: > void synchronize_rcu(void) > { > write_lock(&rcu_gp_mutex); > + smp_mb__after_spinlock(); > write_unlock(&rcu_gp_mutex); > } > > @@ -607,12 +608,15 @@ don't forget about them when submitting patches making use of RCU!] > > The rcu_read_lock() and rcu_read_unlock() primitive read-acquire > and release a global reader-writer lock. The synchronize_rcu() > -primitive write-acquires this same lock, then immediately releases > -it. This means that once synchronize_rcu() exits, all RCU read-side > -critical sections that were in progress before synchronize_rcu() was > -called are guaranteed to have completed -- there is no way that > -synchronize_rcu() would have been able to write-acquire the lock > -otherwise. > +primitive write-acquires this same lock, then releases it. This means > +that once synchronize_rcu() exits, all RCU read-side critical sections > +that were in progress before synchronize_rcu() was called are guaranteed > +to have completed -- there is no way that synchronize_rcu() would have > +been able to write-acquire the lock otherwise. The smp_mb__after_spinlock() > +promotes synchronize_rcu() to a full memory barrier in compliance with > +the "Memory-Barrier Guarantees" listed in: > + > + Documentation/RCU/Design/Requirements/Requirements.html. > > It is possible to nest rcu_read_lock(), since reader-writer locks may > be recursively acquired. Note also that rcu_read_lock() is immune > -- > 2.7.4 >
| |