[3/7] rcu: Document self-propagating callbacks

Commit Message

Paul E. McKenney Jan. 16, 2025, 8:02 p.m. UTC

This commit documents the fact that a given RCU callback function can
repost itself.

Reported-by: Jens Axboe <[e-mail]>
Signed-off-by: Paul E. McKenney <[e-mail]>
---
 kernel/rcu/tree.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Jens Axboe Jan. 16, 2025, 9:38 p.m. UTC | #1

On 1/16/25 1:02 PM, Paul E. McKenney wrote:
> This commit documents the fact that a given RCU callback function can
> repost itself.

Thanks for adding this!

Patch

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 24f1cb292a92d..befe35058c49a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3128,7 +3128,7 @@  module_param(enable_rcu_lazy, bool, 0444);
  * critical sections have completed.
  *
  * Use this API instead of call_rcu() if you don't want the callback to be
- * invoked after very long periods of time, which can happen on systems without
+ * delayed for very long periods of time, which can happen on systems without
  * memory pressure and on systems which are lightly loaded or mostly idle.
  * This function will cause callbacks to be invoked sooner than later at the
  * expense of extra power. Other than that, this function is identical to, and
@@ -3159,6 +3159,12 @@  EXPORT_SYMBOL_GPL(call_rcu_hurry);
  * might well execute concurrently with RCU read-side critical sections
  * that started after call_rcu() was invoked.
  *
+ * It is perfectly legal to repost an RCU callback, potentially with
+ * a different callback function, from within its callback function.
+ * The specified function will be invoked after another full grace period
+ * has elapsed.  This use case is similar in form to the common practice
+ * of reposting a timer from within its own handler.
+ *
  * RCU read-side critical sections are delimited by rcu_read_lock()
  * and rcu_read_unlock(), and may be nested.  In addition, but only in
  * v5.0 and later, regions of code across which interrupts, preemption,