| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20181030222649.GA105735@joelaf.mtv.corp.google.com> Date: Tue, 30 Oct 2018 15:26:49 -0700 From: Joel Fernandes <joel@...lfernandes.org> To: paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org Subject: Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu 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@...lfernandes.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> </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 > -- > 2.19.1.568.g152ad8e336-goog >
Powered by blists - more mailing lists