From: Al Viro <viro@zeniv.linux.org.uk>
To: Baokun Li <libaokun1@huawei.com>
Cc: chengzhihao1@huawei.com, yangerkun@huawei.com,
linux-kernel@vger.kernel.org, huyue2@coolpad.com,
yukuai3@huawei.com, linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH] erofs: fix lockdep false positives on initializing erofs_pseudo_mnt
Date: Thu, 7 Mar 2024 08:46:08 +0000 [thread overview]
Message-ID: <20240307084608.GD538574@ZenIV> (raw)
In-Reply-To: <20240307072112.GC538574@ZenIV>
On Thu, Mar 07, 2024 at 07:21:12AM +0000, Al Viro wrote:
> On Thu, Mar 07, 2024 at 03:06:49PM +0800, Baokun Li wrote:
> > > > +int erofs_anon_register_fs(void)
> > > > +{
> > > > + return register_filesystem(&erofs_anon_fs_type);
> > > > +}
> > > What for? The only thing it gives you is an ability to look it up by
> > > name. Which is completely pointless, IMO,
> > The helper function here is to avoid extern erofs_anon_fs_type(), because
> > we define it in fscache.c, but also use it in super.c. Moreover, we don't
> > need
> > to register it when CONFIG_EROFS_FS_ONDEMAND is not enabled, so we
>
> You don't need to register it at all.
>
> The one and only effect of register_filesystem() is making file_system_type
> instance visible to get_fs_type() (and making it show up in /proc/filesystems).
>
> That's it. If you want to have it looked up by name (e.g. for userland
> mounts), you need to register. If not, you do not need to do that.
>
> Note that kern_mount() take a pointer to struct file_system_type,
> not its (string) name. So all you get from registration is an extra line
> in /proc/filesystems. What's the point?
PS: at one point I considered renaming it to something that would sound
less vague, but the best variant I'd been able to come up with was
"publish_filesystem()", which is not much better and has an extra problem -
how do you describe the reverse of that? "withdraw_filesystem()"?
Decided that it wasn't worth the amount of noise and headache...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Baokun Li <libaokun1@huawei.com>
Cc: linux-erofs@lists.ozlabs.org, xiang@kernel.org, chao@kernel.org,
huyue2@coolpad.com, jefflexu@linux.alibaba.com,
linux-kernel@vger.kernel.org, yangerkun@huawei.com,
houtao1@huawei.com, yukuai3@huawei.com, chengzhihao1@huawei.com
Subject: Re: [PATCH] erofs: fix lockdep false positives on initializing erofs_pseudo_mnt
Date: Thu, 7 Mar 2024 08:46:08 +0000 [thread overview]
Message-ID: <20240307084608.GD538574@ZenIV> (raw)
In-Reply-To: <20240307072112.GC538574@ZenIV>
On Thu, Mar 07, 2024 at 07:21:12AM +0000, Al Viro wrote:
> On Thu, Mar 07, 2024 at 03:06:49PM +0800, Baokun Li wrote:
> > > > +int erofs_anon_register_fs(void)
> > > > +{
> > > > + return register_filesystem(&erofs_anon_fs_type);
> > > > +}
> > > What for? The only thing it gives you is an ability to look it up by
> > > name. Which is completely pointless, IMO,
> > The helper function here is to avoid extern erofs_anon_fs_type(), because
> > we define it in fscache.c, but also use it in super.c. Moreover, we don't
> > need
> > to register it when CONFIG_EROFS_FS_ONDEMAND is not enabled, so we
>
> You don't need to register it at all.
>
> The one and only effect of register_filesystem() is making file_system_type
> instance visible to get_fs_type() (and making it show up in /proc/filesystems).
>
> That's it. If you want to have it looked up by name (e.g. for userland
> mounts), you need to register. If not, you do not need to do that.
>
> Note that kern_mount() take a pointer to struct file_system_type,
> not its (string) name. So all you get from registration is an extra line
> in /proc/filesystems. What's the point?
PS: at one point I considered renaming it to something that would sound
less vague, but the best variant I'd been able to come up with was
"publish_filesystem()", which is not much better and has an extra problem -
how do you describe the reverse of that? "withdraw_filesystem()"?
Decided that it wasn't worth the amount of noise and headache...
next prev parent reply other threads:[~2024-03-07 8:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 2:44 [PATCH] erofs: fix lockdep false positives on initializing erofs_pseudo_mnt Baokun Li via Linux-erofs
2024-03-07 2:44 ` Baokun Li
2024-03-07 2:52 ` Gao Xiang
2024-03-07 2:52 ` Gao Xiang
2024-03-07 3:31 ` Baokun Li via Linux-erofs
2024-03-07 3:31 ` Baokun Li
2024-03-07 3:41 ` Jingbo Xu
2024-03-07 3:41 ` Jingbo Xu
2024-03-07 4:18 ` Gao Xiang
2024-03-07 4:18 ` Gao Xiang
2024-03-07 9:17 ` Christian Brauner
2024-03-07 9:17 ` Christian Brauner
2024-03-07 9:20 ` Gao Xiang
2024-03-07 9:20 ` Gao Xiang
2024-03-07 6:46 ` Baokun Li via Linux-erofs
2024-03-07 6:46 ` Baokun Li
2024-03-07 6:50 ` Gao Xiang
2024-03-07 6:50 ` Gao Xiang
2024-03-07 5:07 ` Al Viro
2024-03-07 5:07 ` Al Viro
2024-03-07 7:06 ` Baokun Li via Linux-erofs
2024-03-07 7:06 ` Baokun Li
2024-03-07 7:21 ` Al Viro
2024-03-07 7:21 ` Al Viro
2024-03-07 7:43 ` Baokun Li via Linux-erofs
2024-03-07 7:43 ` Baokun Li
2024-03-07 8:46 ` Al Viro [this message]
2024-03-07 8:46 ` Al Viro
2024-03-07 9:08 ` Baokun Li via Linux-erofs
2024-03-07 9:08 ` Baokun Li
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=20240307084608.GD538574@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=chengzhihao1@huawei.com \
--cc=huyue2@coolpad.com \
--cc=libaokun1@huawei.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yangerkun@huawei.com \
--cc=yukuai3@huawei.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 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.