diff options
author | Paul E. McKenney <paulmck@kernel.org> | 2023-11-24 14:55:37 -0800 |
---|---|---|
committer | Boqun Feng <boqun.feng@gmail.com> | 2024-02-14 07:53:49 -0800 |
commit | 120311acb01d7360dcc70c0862c83758fbcd28d2 (patch) | |
tree | 57c50d1c5e3b886e2daadbd3924bbd5628226880 | |
parent | 41bccc98fb7931d63d03f326a746ac4d429c1dd3 (diff) | |
download | linux-stable-120311acb01d7360dcc70c0862c83758fbcd28d2.tar.gz linux-stable-120311acb01d7360dcc70c0862c83758fbcd28d2.tar.bz2 linux-stable-120311acb01d7360dcc70c0862c83758fbcd28d2.zip |
doc: Spinlocks are implied RCU readers
In kernels built with CONFIG_PREEMPT_RT=n, spinlock critical sections
are RCU readers because they disable preemption. However, they are also
RCU readers in CONFIG_PREEMPT_RT=y because the -rt locking primitives
contain rcu_read_lock() and rcu_read_unlock(). Therefore, upgrade
rcu_dereference.rst to document this non-obvious case.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Closes: https://lore.kernel.org/lkml/CAHk-=whGKvjHCtJ6W4pQ0_h_k9fiFQ8V2GpM=BqYnB2X=SJ+XQ@mail.gmail.com/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
-rw-r--r-- | Documentation/RCU/rcu_dereference.rst | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst index 659d5913784d..2524dcdadde2 100644 --- a/Documentation/RCU/rcu_dereference.rst +++ b/Documentation/RCU/rcu_dereference.rst @@ -408,7 +408,10 @@ member of the rcu_dereference() to use in various situations: RCU flavors, an RCU read-side critical section is entered using rcu_read_lock(), anything that disables bottom halves, anything that disables interrupts, or anything that disables - preemption. + preemption. Please note that spinlock critical sections + are also implied RCU read-side critical sections, even when + they are preemptible, as they are in kernels built with + CONFIG_PREEMPT_RT=y. 2. If the access might be within an RCU read-side critical section on the one hand, or protected by (say) my_lock on the other, |