From: Tycho Andersen <tandersen@netflix.com>

Signed-off-by: Tycho Andersen <tandersen@netflix.com>
---
 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

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
>