From: Tejun Heo <tj@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
"Michal Koutný" <mkoutny@suse.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Hillf Danton" <hdanton@sina.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Marco Elver" <elver@google.com>,
tglx@linutronix.de
Subject: Re: [PATCH v5 5/6] kernfs: Use RCU to access kernfs_node::parent.
Date: Wed, 29 Jan 2025 06:54:33 -1000 [thread overview]
Message-ID: <Z5pdSZ6akuLnfGMI@slm.duckdns.org> (raw)
In-Reply-To: <20250129132311.rQM6LtB2@linutronix.de>
Hello,
On Wed, Jan 29, 2025 at 02:23:11PM +0100, Sebastian Andrzej Siewior wrote:
> > > @@ -64,9 +64,9 @@ static size_t kernfs_depth(struct kernfs_node *from, struct kernfs_node *to)
> > > {
> > > size_t depth = 0;
> > >
> > > - while (to->parent && to != from) {
> > > + while (rcu_dereference(to->__parent) && to != from) {
> >
> > Why not use kernfs_parent() here and other places?
>
> Because it is from within RCU section and the other checks are not
> required. If you prefer this instead, I sure can update it.
Hmm... I would have gone with using the same accessor everywhere but am not
sure how strongly I feel about it. I don't think it's useful to worry about
the overhead of the extra lockdep annotations in debug builds. Ignoring that
and just considering code readability, what would you do?
> > > @@ -226,6 +227,7 @@ int kernfs_path_from_node(struct kernfs_node *to, struct kernfs_node *from,
> > > unsigned long flags;
> > > int ret;
> > >
> > > + guard(rcu)();
> >
> > Doesn't irqsave imply rcu?
>
> hmm. It kind of does based on the current implementation but it is not
> obvious. We had RCU-sched and RCU which got merged. From then on, the
> (implied) preempt-off part of IRQSAVE should imply RCU (section).
> It is good to be obvious about RCU.
There's that but it can also be confusing to have redundant annotations
especially because redundant things tend to become really inconsistent over
time. After the RCU type merges, ISTR removing annotations that became
redundant in several places.
> Also, rcu_dereference() will complain about missing RCU annotation. On
> PREEMPT_RT rcu_dereference_sched() will complain because irqsave (in
> this case) will not disable interrupts.
You know this a lot better than I do. If it's necessary for RT builds, it's
not redundant.
> > > diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs-internal.h
> > > index b42ee6547cdc1..c43bee18b79f7 100644
> > > --- a/fs/kernfs/kernfs-internal.h
> > > +++ b/fs/kernfs/kernfs-internal.h
> > > @@ -64,11 +66,14 @@ struct kernfs_root {
> > > *
> > > * Return: the kernfs_root @kn belongs to.
> > > */
> > > -static inline struct kernfs_root *kernfs_root(struct kernfs_node *kn)
> > > +static inline struct kernfs_root *kernfs_root(const struct kernfs_node *kn)
> > > {
> > > + const struct kernfs_node *knp;
> > > /* if parent exists, it's always a dir; otherwise, @sd is a dir */
> > > - if (kn->parent)
> > > - kn = kn->parent;
> > > + guard(rcu)();
> > > + knp = rcu_dereference(kn->__parent);
> > > + if (knp)
> > > + kn = knp;
> > > return kn->dir.root;
> > > }
> >
> > This isn't a new problem but the addition of the rcu guard makes it stick
> > out more: What keeps the returned root safe to dereference?
>
> As far as I understand it kernfs_root is around as long as the
> filesystem itself is around which means at least one node needs to stay.
> If you have a pointer to a kernfs_node you should own a reference.
> The RCU section is only needed to ensure that the (current) __parent is
> not replaced and then deallocated before the caller had a chance to
> obtain the root pointer.
That sounds reasonable to me.
Thanks.
--
tejun
next prev parent reply other threads:[~2025-01-29 16:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 8:42 [PATCH v5 0/6] kernfs: Use RCU to access kernfs_node::{parent|name} Sebastian Andrzej Siewior
2025-01-28 8:42 ` [PATCH v5 1/6] kernfs: Acquire kernfs_rwsem in kernfs_notify_workfn() Sebastian Andrzej Siewior
2025-01-28 8:42 ` [PATCH v5 2/6] kernfs: Acquire kernfs_rwsem in kernfs_get_parent_dentry() Sebastian Andrzej Siewior
2025-01-28 8:42 ` [PATCH v5 3/6] kernfs: Acquire kernfs_rwsem in kernfs_node_dentry() Sebastian Andrzej Siewior
2025-01-28 8:42 ` [PATCH v5 4/6] kernfs: Don't re-lock kernfs_root::kernfs_rwsem in kernfs_fop_readdir() Sebastian Andrzej Siewior
2025-01-28 8:42 ` [PATCH v5 5/6] kernfs: Use RCU to access kernfs_node::parent Sebastian Andrzej Siewior
2025-01-28 20:31 ` Tejun Heo
2025-01-29 13:23 ` Sebastian Andrzej Siewior
2025-01-29 16:54 ` Tejun Heo [this message]
2025-01-29 20:26 ` Sebastian Andrzej Siewior
2025-01-29 20:29 ` Tejun Heo
2025-01-28 8:42 ` [PATCH v5 6/6] kernfs: Use RCU to access kernfs_node::name Sebastian Andrzej Siewior
2025-01-28 20:40 ` Tejun Heo
2025-01-29 14:21 ` Sebastian Andrzej Siewior
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=Z5pdSZ6akuLnfGMI@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=elver@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=paulmck@kernel.org \
--cc=tglx@linutronix.de \
/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®