Re: [PATCH] rcutorture: Clear cbflood_max for tasks-rude and srcu-atomic testing

[Joel Fernandes <joelagnelf@nvidia.com>]

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 <qiang.zhang@linux.dev>
> ---
>  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