Commit 21ef2498 authored by Paul E. McKenney's avatar Paul E. McKenney Committed by Boqun Feng
Browse files

rcu: Document self-propagating callbacks 



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

Reported-by: default avatarJens Axboe <axboe@kernel.dk>
Signed-off-by: default avatarPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: default avatarBoqun Feng <boqun.feng@gmail.com>
parent df0cee43

kernel/rcu/tree.c

+7 −1
Original line number Diff line number Diff line
@@ -3107,7 +3107,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
@@ -3138,6 +3138,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,