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

["Zqiang" <qiang.zhang@linux.dev>]

> 
> 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?

Agree, the 'cur_ops == &rcu_busted_ops' check can be removed.

Thanks
Zqiang

> 
> thanks,
> 
> Joel Fernandes
>