Re: [PATCH v2] rcutorture: Avoid create fwd_prog_tasks for tasks-rude and srcu-atomic

["Paul E. McKenney" <paulmck@kernel.org>]

On Fri, Oct 23, 2026 at 05:37:16PM +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 adds
> ->call and ->cb_barrier to the forward-progress check, rejecting flavors
> that lack the cbflood_max set and a positive ->stall_dur.
> 
> 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
> 
> Suggested-by: Joel Fernandes <joelagnelf@nvidia.com> 
> Signed-off-by: Zqiang <qiang.zhang@linux.dev>

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

It would nevertheless be good to run tests demonstrating that
forward-progress testing happens and does not happen on the same
rcu_torture_ops structures as before.  Just in case I lost my
way through that boolean expression.  ;-)

> ---
>  kernel/rcu/rcutorture.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 968343be4e0d..92ff197f4789 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -4007,9 +4007,8 @@ static int __init rcu_torture_fwd_prog_init(void)
>  	} else if (fwd_progress < 0) {
>  		fwd_progress = nr_cpu_ids;
>  	}
> -	if ((!cur_ops->sync && !cur_ops->call) ||
> -	    (!cur_ops->cbflood_max && (!cur_ops->stall_dur || cur_ops->stall_dur() <= 0)) ||
> -	    cur_ops == &rcu_busted_ops) {
> +	if (!cur_ops->sync || ((!cur_ops->call || !cur_ops->cb_barrier || !cur_ops->cbflood_max) &&
> +	    (!cur_ops->stall_dur || cur_ops->stall_dur() <= 0))) {
>  		VERBOSE_TOROUT_STRING("rcu_torture_fwd_prog_init: Disabled, unsupported by RCU flavor under test");
>  		fwd_progress = 0;
>  		return 0;
> -- 
> 2.17.1
>