All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zqiang" <qiang.zhang@linux.dev>
To: "Bradley Morgan" <brads@mainlining.org>
Cc: boqun@kernel.org, frederic@kernel.org, joelagnelf@nvidia.com,
	linux-kernel@vger.kernel.org, neeraj.upadhyay@kernel.org,
	paulmck@kernel.org, rcu@vger.kernel.org, urezki@gmail.com
Subject: Re: [PATCH] rcutorture: Clear cbflood_max for tasks-rude and srcu-atomic testing
Date: Fri, 16 Oct 2026 23:46:47 +0000	[thread overview]
Message-ID: <a7d7a54442035f8401d8dd55546ee549f28f1c49@linux.dev> (raw)
In-Reply-To: <CB7858D2-103F-4EB5-8A7B-55E1A65042FA@mainlining.org>

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

      reply	other threads:[~2026-10-16 23:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 10:41 [PATCH] rcutorture: Clear cbflood_max for tasks-rude and srcu-atomic testing Zqiang
2026-10-12 14:50 ` Bradley Morgan
2026-10-16 23:46   ` Zqiang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7d7a54442035f8401d8dd55546ee549f28f1c49@linux.dev \
    --to=qiang.zhang@linux.dev \
    --cc=boqun@kernel.org \
    --cc=brads@mainlining.org \
    --cc=frederic@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.