Message ID | 20230607141521.539828-1-tycho@tycho.pizza (mailing list archive) |
---|---|
State | Accepted |
Commit | 862d21e4a70285cf3f4c56f074ccee5a6d019d4b |
Headers | show |
Series | documentation/rcu: fix typo | expand |
On Wed, Jun 07, 2023 at 08:15:21AM -0600, Tycho Andersen wrote: > From: Tycho Andersen <tandersen@netflix.com> > > Signed-off-by: Tycho Andersen <tandersen@netflix.com> Good eyes, queued, thank you! Build a fence out of all those lockdep-RCU slats? ;-) Thanx, Paul > --- > Documentation/RCU/lockdep-splat.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/RCU/lockdep-splat.rst b/Documentation/RCU/lockdep-splat.rst > index 2a5c79db57dc..bcbc4b3c88d7 100644 > --- a/Documentation/RCU/lockdep-splat.rst > +++ b/Documentation/RCU/lockdep-splat.rst > @@ -10,7 +10,7 @@ misuses of the RCU API, most notably using one of the rcu_dereference() > family to access an RCU-protected pointer without the proper protection. > When such misuse is detected, an lockdep-RCU splat is emitted. > > -The usual cause of a lockdep-RCU slat is someone accessing an > +The usual cause of a lockdep-RCU splat is someone accessing an > RCU-protected data structure without either (1) being in the right kind of > RCU read-side critical section or (2) holding the right update-side lock. > This problem can therefore be serious: it might result in random memory > > base-commit: a4d7d701121981e3c3fe69ade376fe9f26324161 > -- > 2.34.1 >
diff --git a/Documentation/RCU/lockdep-splat.rst b/Documentation/RCU/lockdep-splat.rst index 2a5c79db57dc..bcbc4b3c88d7 100644 --- a/Documentation/RCU/lockdep-splat.rst +++ b/Documentation/RCU/lockdep-splat.rst @@ -10,7 +10,7 @@ misuses of the RCU API, most notably using one of the rcu_dereference() family to access an RCU-protected pointer without the proper protection. When such misuse is detected, an lockdep-RCU splat is emitted. -The usual cause of a lockdep-RCU slat is someone accessing an +The usual cause of a lockdep-RCU splat is someone accessing an RCU-protected data structure without either (1) being in the right kind of RCU read-side critical section or (2) holding the right update-side lock. This problem can therefore be serious: it might result in random memory