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

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

[Zqiang]

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"
 };
-- 
2.17.1

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

[Bradley Morgan]

On 12 October 2026 11:41:34 BST, Zqiang <qiang.zhang@linux.dev> 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

Fixes tag?

This LGTM anyway so:

Reviewed-by: Bradley Morgan <brads@mainlining.org>

>
>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"
> };
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

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

[Zqiang]

> 
> On 12 October 2026 11:41:34 BST, Zqiang <qiang.zhang@linux.dev> 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
> > 
> Fixes tag?
> 
> This LGTM anyway so:
> 
> Reviewed-by: Bradley Morgan <brads@mainlining.org>

Thanks for reviewed !!

Thanks
Zqiang

> 
> > 
> > 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"
> >  };
> > 
> --- Thanks!
> "I'm not a very positive person" - Linus torvalds
>

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

[Joel Fernandes]

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

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

[Zqiang]

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