[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <utvrepwokhocoqipz3l2nwe6gc7ly7jbvanr2q4mfngw4lt5aw@tsb36jutqrci>
Date: Wed, 11 Dec 2024 16:36:20 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
"Paul E. McKenney" <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hillf Danton <hdanton@...a.com>,
Johannes Weiner <hannes@...xchg.org>, Marco Elver <elver@...gle.com>, Tejun Heo <tj@...nel.org>,
tglx@...utronix.de, syzbot+6ea37e2e6ffccf41a7e6@...kaller.appspotmail.com
Subject: Re: [PATCH v3] kernfs: Use RCU for kernfs_node::name and ::parent
lookup.
On Mon, Nov 25, 2024 at 07:02:26PM GMT, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> Assuming the parent can't vanish in these cases, name could during the
> invocation.
^^^^^^^^^^
So those R-locks are likely missing even prior this RCUization (as
pointed out by Tejun).
If I don't miss context, this would be better a separate pre-patch.
> I can't keep the RCU read section open while there is a
> sleep within the call chain. Therefore I added the lock so the
> rcu_dereference.*() is quiet.
Ah, right.
>
> > (Perhaps it's related to second observation I have -- why there is
> > sometimes kernfs_rcu_get_parent() whereas there are other call sites
> > with mere rcu_dereference(kn->parent)?)
>
> rcu_dereference() is used where I was sure that there is always a RCU
> read section. I have kernfs_rcu_get_parent() when there is either a RCU
> read section or the kernfs_rwsem (or just the lock).
I think context-less rcu_dereference_check wrapper (with a comment)
could capture that semantics too.
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists