>
> 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?
Agree, the 'cur_ops == &rcu_busted_ops' check can be removed.
Thanks
Zqiang
>
> thanks,
>
> Joel Fernandes
>
