From: Boqun Feng <boqun.feng@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
"Paul E. McKenney" <paulmck@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Peter Zijlstra <peterz@infradead.org>,
Johannes Berg <johannes.berg@intel.com>
Subject: Re: [PATCH] rcu: mollify sparse with RCU guard
Date: Mon, 25 Mar 2024 09:35:04 -0700 [thread overview]
Message-ID: <ZgGnuFJiTX5laS7c@boqun-archlinux> (raw)
In-Reply-To: <20240325101626.41584-2-johannes@sipsolutions.net>
On Mon, Mar 25, 2024 at 11:16:27AM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When using "guard(rcu)();" sparse will complain, because even
> though it now understands the cleanup attribute, it doesn't
> evaluate the calls from it at function exit, and thus doesn't
> count the context correctly.
>
> Given that there's a conditional in the resulting code:
>
> static inline void class_rcu_destructor(class_rcu_t *_T)
> {
> if (_T->lock) {
> rcu_read_unlock();
> }
> }
>
> it seems that even trying to teach sparse to evalulate the
> cleanup attribute function it'd still be difficult to really
> make it understand the full context here.
>
> Suppress the sparse warning by just releasing the context in
> the acquisition part of the function, after all we know it's
> safe with the guard, that's the whole point of it.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> include/linux/rcupdate.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 17d7ed5f3ae6..41081ee9c9a7 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -1090,6 +1090,6 @@ rcu_head_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
> extern int rcu_expedited;
> extern int rcu_normal;
>
> -DEFINE_LOCK_GUARD_0(rcu, rcu_read_lock(), rcu_read_unlock())
> +DEFINE_LOCK_GUARD_0(rcu, do { rcu_read_lock(); __release(RCU); } while(0), rcu_read_unlock())
>
Hmm.. not a big fan of this. __release(RCU) following a rcu_read_lock()
is really confusing. Maybe we can introduce a _rcu_read_lock():
void _rcu_read_lock(bool guard) {
__rcu_read_lock();
// Skip sparse annotation in "guard(rcu)()" to work
// around sparse's lack of support of cleanup.
if (!guard)
__acquire(RCU);
rcu_lock_acquire(...);
...
}
and normal rcu_read_lock() is just a _rcu_read_lock(false), RCU guard is
a _rcu_read_lock(true)?
But before that how does it looks if we don't fix this entirely? ;-)
Regards,
Boqun
> #endif /* __LINUX_RCUPDATE_H */
> --
> 2.44.0
>
next prev parent reply other threads:[~2024-03-25 16:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 10:16 [PATCH] rcu: mollify sparse with RCU guard Johannes Berg
2024-03-25 16:35 ` Boqun Feng [this message]
2024-03-25 16:41 ` Johannes Berg
2024-03-25 17:33 ` Boqun Feng
2024-03-25 18:28 ` Dan Carpenter
2024-03-25 18:43 ` Johannes Berg
2024-03-26 7:39 ` Dan Carpenter
2024-03-26 7:53 ` Johannes Berg
2024-03-26 8:20 ` Dan Carpenter
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=ZgGnuFJiTX5laS7c@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
/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.