On Mon, Oct 12, 2026 at 06:41:34PM +0800, Zqiang wrote:
> When running the tasks-rude and srcu-atomic tests, the fwd_prog_tasks
> kthread is created because the default value of fwd_progress is 1.
> however, the two RCU flavors not support ->call():
>
> 1. tasks-rude: commit b428a9de9bba ("rcutorture: Stop testing RCU Tasks
> Rude asynchronous APIs") removed .call and .cb_barrier from tasks-rude,
> but left the .cbflood_max = 50000.
>
> 2. srcu-atomic: srcu_torture_init_forbidden_apis() sets ->call to NULL
> for SRCU_READ_FLAVOR_ATOMIC runs, but leaves ->cbflood_max untouched.
>
> In both cases, the non-zero ->cbflood_max fools the check above into
> creating the fwd_prog_tasks kthreads, even though those kthreads cannot
> possibly carry out any forward-progress test:
>
> 1. The rcu_torture_fwd_prog_cr() returns immediately due to cur_ops->call
> is NULL:
>
> [ 68.022674] rcu_torture_fwd_prog_cr: No ->call(), so no forward-progress
> test 0
> [ 129.462046] rcu_torture_fwd_prog_cr: No ->call(), so no forward-progress
> test 0
> [ 190.902123] rcu_torture_fwd_prog_cr: No ->call(), so no forward-progress
> test 0
> [ 252.343809] rcu_torture_fwd_prog_cr: No ->call(), so no forward-progress
> test 0
>
> 2. The rcu_torture_fwd_prog_nr() is never even invoked, because its caller
> requires cur_ops->stall_dur, and neither tasks-rude nor srcu-atomic
> provide ->stall_dur (only rcu_ops does).
>
> Therefore, creating fwd_prog_tasks kthreads is pointless, this commit
> removes the .cbflood_max from tasks-rude and clears ->cbflood_max in the
> srcu_torture_init_forbidden_apis().
>
> simple verification output:
>
> [ 3.062959][ T1] srcu-torture: rcu_torture_fwd_prog_init: Disabled,
> unsupported by RCU flavor under test
> [ 2.922323][ T1] tasks-rude-torture: rcu_torture_fwd_prog_init:
> Disabled, unsupported by RCU flavor under test
>
> Signed-off-by: Zqiang <[email protected]>
> ---
> kernel/rcu/rcutorture.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 968343be4e0d..00db87256e78 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -723,6 +723,7 @@ static void srcu_torture_init_forbidden_apis(void)
> cur_ops->deferred_free = NULL;
> cur_ops->exp_current = NULL;
> cur_ops->start_gp_poll = NULL;
> + cur_ops->cbflood_max = 0;
> }
>
> static void srcu_torture_init(void)
> @@ -1250,7 +1251,6 @@ static struct rcu_torture_ops tasks_rude_ops = {
> .exp_sync = synchronize_rcu_tasks_rude,
> .gp_kthread_dbg = show_rcu_tasks_rude_gp_kthread,
> .get_gp_data = rcu_tasks_rude_get_gp_data,
> - .cbflood_max = 50000,
> .irq_capable = 1,
> .name = "tasks-rude"
I'm okay with your change, but I have a different suggestion. Let me know your
thoughts.
Could we fix this in rcu_torture_fwd_prog_init() instead? A nonzero
cbflood_max does not mean callback flooding is possible when ->call or
->cb_barrier is absent. This also avoids changing the SRCU operations table
just to suppress a worker.
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -3842,3 +3842,4 @@ static int __init rcu_torture_fwd_prog_init(void)
- if ((!cur_ops->sync && !cur_ops->call) ||
- (!cur_ops->cbflood_max && (!cur_ops->stall_dur ||
cur_ops->stall_dur() <= 0)) ||
+ if (!cur_ops->sync ||
+ ((!cur_ops->call || !cur_ops->cb_barrier || !cur_ops->cbflood_max)
&&
+ (!cur_ops->stall_dur || cur_ops->stall_dur() <= 0)) ||
cur_ops == &rcu_busted_ops) {
Thoughts?
thanks,
Joel Fernandes
