From: Joel Fernandes <joelagnelf@nvidia.com>
To: Zqiang <qiang.zhang@linux.dev>
Cc: "paulmck@kernel.org" <paulmck@kernel.org>,
"frederic@kernel.org" <frederic@kernel.org>,
"neeraj.upadhyay@kernel.org" <neeraj.upadhyay@kernel.org>,
"urezki@gmail.com" <urezki@gmail.com>,
"boqun@kernel.org" <boqun@kernel.org>,
"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] rcutorture: Avoid create fwd_prog_tasks for tasks-rude and srcu-atomic
Date: Fri, 30 Oct 2026 12:46:55 +0000 [thread overview]
Message-ID: <ACA82057-9E74-41CD-8EEE-1D59E98D2D41@nvidia.com> (raw)
> On Oct 30, 2026, at 8:14 AM, Zqiang <qiang.zhang@linux.dev> wrote:
>
>
>>
>>
>>> 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. ;-)
>
> Ok, I see. thanks Paul ;-) .
So let me know Zqiang once you are confident on the testing from and I will apply it for 7.5.
thanks,
Joel Fernandes
>
>>
>>>
>>> ---
>>> 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
>>>
>>
next reply other threads:[~2026-10-30 12:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 12:46 Joel Fernandes [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-10-23 9:37 Zqiang
2026-10-23 19:23 ` Paul E. McKenney
2026-10-30 12:14 ` Zqiang
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=ACA82057-9E74-41CD-8EEE-1D59E98D2D41@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=boqun@kernel.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=qiang.zhang@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®