From: Joel Fernandes <joelagnelf@nvidia.com>
To: paulmck@kernel.org
Cc: linux-kernel@vger.kernel.org,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun.feng@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang@linux.dev>,
rcu@vger.kernel.org
Subject: Re: [PATCH -rcu -next 4/7] rcu: Remove redundant check for irq state during unlock
Date: Fri, 11 Jul 2025 14:19:47 -0400 [thread overview]
Message-ID: <3d1217a9-2d22-4808-adca-0fdf78278a36@nvidia.com> (raw)
In-Reply-To: <c25c1084-ef70-409b-b38f-84c69e08e562@paulmck-laptop>
On 7/11/2025 1:18 PM, Paul E. McKenney wrote:
> On Fri, Jul 11, 2025 at 12:30:08PM -0400, Joel Fernandes wrote:
>>
>>
>> On 7/10/2025 8:00 PM, Paul E. McKenney wrote:
>>> On Tue, Jul 08, 2025 at 10:22:21AM -0400, Joel Fernandes wrote:
>>>> The check for irqs_were_disabled is redundant in
>>>> rcu_unlock_needs_exp_handling() as the caller already checks for this.
>>>> This includes the boost case as well. Just remove the redundant check.
>>>
>>> But in the very last "if" statement in the context of the last hunk of
>>> this patch, isn't it instead checking for !irqs_were_disabled?
>>>
>>> Or is there something that I am missing that makes this work out OK?
>>
>> You are right, after going over all the cases I introduced a behavioral change.
>>
>> Say, irqs_were_disabled was false. And say we are RCU-boosted. needs_exp might
>> return true now, but previously it was returning false. Further say, we are not
>> in hardirq.
>>
>> New code will raise softirq, old code would go to the ELSE and just set:
>> set_tsk_need_resched(current);
>> set_preempt_need_resched();
>>
>> But preempt_bh_were_disabled that's why we're here.
>>
>> So we need to only set resched and not raise softirq, because the preempt enable
>> would reschedule.
>>
>> Sorry I missed this, but unless this behavior is correct or needs further work,
>> lets drop this patch. Thanks and kudos on the catch!
>
> Not a problem!
>
> You can use cbmc to check these sorts of transformations, as described
> here: https://paulmck.livejournal.com/38997.html
Much appreciated! Does the tool automatically create stubs for dependent
structures or is that upto the CBMC user? I see in your example in the blog you
did create an rcu_node :). I wonder if for large number of dependencies on the
code base, how it does in terms of overhead for the user.
But perhaps for simpler examples (such as perhaps the above), manually mocking
data structures and dependent code is reasonable?
We'd have to stub irq_work and raise_softirq and functions too and also the
CONFIG option values.
Thanks!
- Joel
next prev parent reply other threads:[~2025-07-11 18:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 14:22 [PATCH -rcu -next 1/7] smp: Document preemption and stop_machine() mutual exclusion Joel Fernandes
2025-07-08 14:22 ` [PATCH -rcu -next 2/7] rcu: Fix rcu_read_unlock() deadloop due to IRQ work Joel Fernandes
2025-07-09 0:00 ` Paul E. McKenney
2025-07-08 14:22 ` [PATCH -rcu -next 3/7] rcu: Refactor expedited handling check in rcu_read_unlock_special() Joel Fernandes
2025-07-09 0:06 ` Paul E. McKenney
2025-07-08 14:22 ` [PATCH -rcu -next 4/7] rcu: Remove redundant check for irq state during unlock Joel Fernandes
2025-07-11 0:00 ` Paul E. McKenney
2025-07-11 16:30 ` Joel Fernandes
2025-07-11 16:39 ` Joel Fernandes
2025-07-11 17:18 ` Paul E. McKenney
2025-07-11 18:19 ` Joel Fernandes [this message]
2025-07-11 18:41 ` Paul E. McKenney
2025-07-08 14:22 ` [PATCH -rcu -next 5/7] rcu: Document GP init vs hotplug-scan ordering requirements Joel Fernandes
2025-07-11 0:01 ` Paul E. McKenney
2025-07-08 14:22 ` [PATCH -rcu -next 6/7] rcu: Document separation of rcu_state and rnp's gp_seq Joel Fernandes
2025-07-11 0:02 ` Paul E. McKenney
2025-07-08 14:22 ` [PATCH -rcu -next 7/7] rcu: Document concurrent quiescent state reporting for offline CPUs Joel Fernandes
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=3d1217a9-2d22-4808-adca-0fdf78278a36@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=qiang.zhang@linux.dev \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.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®