Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 30 Oct 2018 15:26:49 -0700
From:   Joel Fernandes <joel@joelfernandes.org>
To:     paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu
Message-ID: <20181030222649.GA105735@joelaf.mtv.corp.google.com>
References: <20181028043046.198403-1-joel@joelfernandes.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181028043046.198403-1-joel@joelfernandes.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Paul,

On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> As per this thread [1], 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.
> 
> [1] https://lkml.org/lkml/2017/10/6/707
> 
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>

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?

thanks,

- 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>&nbsp;</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>&nbsp;</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>&nbsp;</td></tr>
> -</table>
> -
>  <p>Tree RCU's grace--period memory-ordering guarantees rely most
>  heavily on the <tt>rcu_node</tt> structure's <tt>-&gt;lock</tt>
>  field, so much so that it is necessary to abbreviate this pattern
> -- 
> 2.19.1.568.g152ad8e336-goog
>