Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu
From: Paul E. McKenney
Date: Tue Oct 30 2018 - 19:43:44 EST
On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
> Hi Paul,
> On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> > As per this thread , it seems this smp_mb isn't needed anymore:
> > "So the smp_mb() that I was trying to add doesn't need to be there."
> > So let us remove this part from the memory ordering documentation.
> >  https://lkml.org/lkml/2017/10/6/707
> > Signed-off-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx>
> I was just checking about this patch. Do you feel it is correct to remove
> this part from the docs? Are you satisified that a barrier isn't needed there
> now? Or did I miss something?
Apologies, it got lost in the shuffle. I have now applied it with a
bit of rework to the commit log, thank you!
> - Joel
> > ---
> > .../Tree-RCU-Memory-Ordering.html | 32 +------------------
> > 1 file changed, 1 insertion(+), 31 deletions(-)
> > diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
> > index a346ce0116eb..0fb1511763d4 100644
> > --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
> > +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
> > @@ -77,7 +77,7 @@ The key point is that the lock-acquisition functions, including
> > <tt>smp_mb__after_unlock_lock()</tt> immediately after successful
> > acquisition of the lock.
> > -<p>Therefore, for any given <tt>rcu_node</tt> struction, any access
> > +<p>Therefore, for any given <tt>rcu_node</tt> structure, any access
> > happening before one of the above lock-release functions will be seen
> > by all CPUs as happening before any access happening after a later
> > one of the above lock-acquisition functions.
> > @@ -162,36 +162,6 @@ an <tt>atomic_add_return()</tt> of zero) to detect idle CPUs.
> > <tr><td> </td></tr>
> > </table>
> > -<p>The approach must be extended to handle one final case, that
> > -of waking a task blocked in <tt>synchronize_rcu()</tt>.
> > -This task might be affinitied to a CPU that is not yet aware that
> > -the grace period has ended, and thus might not yet be subject to
> > -the grace period's memory ordering.
> > -Therefore, there is an <tt>smp_mb()</tt> after the return from
> > -<tt>wait_for_completion()</tt> in the <tt>synchronize_rcu()</tt>
> > -code path.
> > -
> > -<table>
> > -<tr><th> </th></tr>
> > -<tr><th align="left">Quick Quiz:</th></tr>
> > -<tr><td>
> > - What? Where???
> > - I don't see any <tt>smp_mb()</tt> after the return from
> > - <tt>wait_for_completion()</tt>!!!
> > -</td></tr>
> > -<tr><th align="left">Answer:</th></tr>
> > -<tr><td bgcolor="#ffffff"><font color="ffffff">
> > - That would be because I spotted the need for that
> > - <tt>smp_mb()</tt> during the creation of this documentation,
> > - and it is therefore unlikely to hit mainline before v4.14.
> > - Kudos to Lance Roy, Will Deacon, Peter Zijlstra, and
> > - Jonathan Cameron for asking questions that sensitized me
> > - to the rather elaborate sequence of events that demonstrate
> > - the need for this memory barrier.
> > -</font></td></tr>
> > -<tr><td> </td></tr>
> > -</table>
> > -
> > <p>Tree RCU's grace--period memory-ordering guarantees rely most
> > heavily on the <tt>rcu_node</tt> structure's <tt>->lock</tt>
> > field, so much so that it is necessary to abbreviate this pattern
> > --
> > 220.127.116.118.g152ad8e336-goog