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: ty...@mit.edu
> > > Suggested-by: ty...@mit.edu
> > > Signed-off-by: Joel Fernandes (Google) <j...@joelfernandes.org>
> >
> > 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
>
