From: Paul E. McKenney Date: Tue, 5 Jul 2022 19:15:35 +0000 (-0700) Subject: doc: Emphasize the need for explicit RCU read-side markers X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=4d2f862b5b49141a1762baa67c846c598b54be27;p=linux.git doc: Emphasize the need for explicit RCU read-side markers This commit updates checklist.rst to emphasize the need for explicit markers for RCU read-side critical sections. Signed-off-by: Paul E. McKenney --- diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 42cc5d891bd26..5eedef027d922 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -66,8 +66,13 @@ over a rather long period of time, but improvements are always welcome! As a rough rule of thumb, any dereference of an RCU-protected pointer must be covered by rcu_read_lock(), rcu_read_lock_bh(), rcu_read_lock_sched(), or by the appropriate update-side lock. - Disabling of preemption can serve as rcu_read_lock_sched(), but - is less readable and prevents lockdep from detecting locking issues. + Explicit disabling of preemption (preempt_disable(), for example) + can serve as rcu_read_lock_sched(), but is less readable and + prevents lockdep from detecting locking issues. + + Please not that you *cannot* rely on code known to be built + only in non-preemptible kernels. Such code can and will break, + especially in kernels built with CONFIG_PREEMPT_COUNT=y. Letting RCU-protected pointers "leak" out of an RCU read-side critical section is every bit as bad as letting them leak out