On Tue, Oct 09, 2018 at 09:01:59PM -0700, Joel Fernandes wrote: > On Tue, Oct 09, 2018 at 08:09:06PM -0700, Paul E. McKenney wrote: > > On Mon, Oct 08, 2018 at 06:33:41PM -0700, Joel Fernandes (Google) wrote: > > > whatisRCU says rcu_dereference cannot be used outside of rcu read lock > > > protected sections. Its better to mention rcu_dereference_protected when > > > it says that, so that the new reader is aware of this API and is not led > > > to believing that all RCU dereferences in all situations have to be > > > protected by a rcu_read_lock() and rcu_read_unlock(). > > > > > > Cc: tytso@xxxxxxx > > > Suggested-by: tytso@xxxxxxx > > > Signed-off-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx> > > > > Good stuff! I queued and pushed this with some wordsmithing. Could > > you please check for my having messed something up? > > One small nit which the below diff should fix, but otherwise looks good to > me, thanks! Good catch! I rolled the into the commit, thank you! Thanx, Paul > - Joel > > ----8<---- > > diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt > index 38044c978e54..093b85ad49eb 100644 > --- a/Documentation/RCU/whatisRCU.txt > +++ b/Documentation/RCU/whatisRCU.txt > @@ -297,7 +297,7 @@ rcu_dereference() > protected by locks acquired by the update-side code. This variant > avoids the lockdep warning that would happen when using (for > example) rcu_dereference() without rcu_read_lock() protection. > - Using rcu_dereference_protected() also have the advantage > + Using rcu_dereference_protected() also has the advantage > of permitting compiler optimizations that rcu_dereference() > must prohibit. The rcu_dereference_protected() variant takes > a lockdep expression to indicate which locks must be acquired >
