]> git.ipfire.org Git - thirdparty/linux.git/commitdiff
doc: Update checklist.rst discussion of callback execution
authorPaul E. McKenney <paulmck@kernel.org>
Wed, 13 Dec 2023 17:49:20 +0000 (09:49 -0800)
committerBoqun Feng <boqun.feng@gmail.com>
Wed, 14 Feb 2024 15:53:50 +0000 (07:53 -0800)
This commit completes the list of call_rcu*() functions that are not
guaranteed to have their callbacks executing on the same CPU.  While in
the area, fix an unrelated typo.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Documentation/RCU/checklist.rst

index addd5c1547a420d2ea1ce8e66264d1cc8f9116e5..3e6407de231c998ac7f0539c3d856458097d8971 100644 (file)
@@ -383,16 +383,17 @@ over a rather long period of time, but improvements are always welcome!
        must use whatever locking or other synchronization is required
        to safely access and/or modify that data structure.
 
-       Do not assume that RCU callbacks will be executed on the same
-       CPU that executed the corresponding call_rcu() or call_srcu().
-       For example, if a given CPU goes offline while having an RCU
-       callback pending, then that RCU callback will execute on some
-       surviving CPU.  (If this was not the case, a self-spawning RCU
-       callback would prevent the victim CPU from ever going offline.)
-       Furthermore, CPUs designated by rcu_nocbs= might well *always*
-       have their RCU callbacks executed on some other CPUs, in fact,
-       for some  real-time workloads, this is the whole point of using
-       the rcu_nocbs= kernel boot parameter.
+       Do not assume that RCU callbacks will be executed on
+       the same CPU that executed the corresponding call_rcu(),
+       call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
+       call_rcu_tasks_trace().  For example, if a given CPU goes offline
+       while having an RCU callback pending, then that RCU callback
+       will execute on some surviving CPU.  (If this was not the case,
+       a self-spawning RCU callback would prevent the victim CPU from
+       ever going offline.)  Furthermore, CPUs designated by rcu_nocbs=
+       might well *always* have their RCU callbacks executed on some
+       other CPUs, in fact, for some  real-time workloads, this is the
+       whole point of using the rcu_nocbs= kernel boot parameter.
 
        In addition, do not assume that callbacks queued in a given order
        will be invoked in that order, even if they all are queued on the