From: Minchan Kim <minchan@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] kernfs: release kernfs_mutex before the inode allocation
Date: Wed, 17 Nov 2021 17:55:33 -0800 [thread overview]
Message-ID: <YZWylT2SuN+N2Z2K@google.com> (raw)
In-Reply-To: <YZWA+8B1xQOKCMnS@slm.duckdns.org>
On Wed, Nov 17, 2021 at 12:23:55PM -1000, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 17, 2021 at 02:13:35PM -0800, Minchan Kim wrote:
> > > So, one really low hanging fruit here would be using a separate rwsem per
> > > superblock. Nothing needs synchronization across different users of kernfs
> > > and the locking is shared just because nobody bothered to separate them out
> > > while generalizing it from sysfs.
> >
> > That's really what I wanted but had a question whether we can access
> > superblock from the kernfs_node all the time since there are some
> > functions to access the kernfs_rwsem without ionde, sb context.
> >
> > Is it doable to get the superblock from the kernfs_node all the time?
>
> Ah, right, kernfs_node doesn't point back to kernfs_root. I guess it can go
> one of three ways:
Thanks for the suggestion, Tejun.
I found kernfs_root and it seems like to return kernfs_root from kernfs_node.
If it's true all the case, we would put the rwsem in kernfs_root and change
would be straightforward. Do you see any problem?
>
> a. Follow parent until root kernfs_node and make that guy point to
> kernfs_root through its parent field. This isn't great but the hotter
> paths all have sb / inode already, I think, so if we do this only in the
> really cold paths, it likely isn't too bad.
>
> b. Change the interface so that the callers have to provide kernfs_root. I
> don't think this is gonna be a huge problem. There are a few users of
> kernfs and they always know their roots.
>
> c. Add a field to kernfs_node so that we can always find kernfs_root.
>
> I think b is likely the cheapest && cleanest.
>
> Thanks.
>
> --
> tejun
next prev parent reply other threads:[~2021-11-18 1:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 19:43 [RFC PATCH] kernfs: release kernfs_mutex before the inode allocation Minchan Kim
2021-11-16 19:49 ` Greg Kroah-Hartman
2021-11-16 21:36 ` Minchan Kim
2021-11-17 6:44 ` Greg Kroah-Hartman
2021-11-17 7:27 ` Minchan Kim
2021-11-17 7:39 ` Greg Kroah-Hartman
2021-11-17 21:43 ` Minchan Kim
2021-11-17 21:45 ` Tejun Heo
2021-11-17 22:13 ` Minchan Kim
2021-11-17 22:23 ` Tejun Heo
2021-11-18 1:55 ` Minchan Kim [this message]
2021-11-18 16:35 ` Tejun Heo
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=YZWylT2SuN+N2Z2K@google.com \
--to=minchan@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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.