[RFC] what's the point of register_filesystem() in drivers/dax/super.c?

[RFC] what's the point of register_filesystem() in drivers/dax/super.c?

[Al Viro]

	It's not user-mountable, kern_mount() doesn't care about
looking it up by name, so the only effect of having it registered
is having it visible in /proc/filesystems.

	Do you need that for anything?  Because I would rather
avoid more of that voodoo...

Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?

[Dan Williams]

On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         It's not user-mountable, kern_mount() doesn't care about
> looking it up by name, so the only effect of having it registered
> is having it visible in /proc/filesystems.
>
>         Do you need that for anything?  Because I would rather
> avoid more of that voodoo...

It can die. It was mindless copy/paste from fs/blockdev.c and the
"bdev" fs. The device-dax unit tests pass just fine with it removed.
I'll send a formal patch with the following:

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index ccb22d8db3a2..3d6a9e61e358 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -615,10 +615,6 @@ static int dax_fs_init(void)
        if (!dax_cache)
                return -ENOMEM;

-       rc = register_filesystem(&dax_fs_type);
-       if (rc)
-               goto err_register_fs;
-
        dax_mnt = kern_mount(&dax_fs_type);
        if (IS_ERR(dax_mnt)) {
                rc = PTR_ERR(dax_mnt);
@@ -629,8 +625,6 @@ static int dax_fs_init(void)
        return 0;

  err_mount:
-       unregister_filesystem(&dax_fs_type);
- err_register_fs:
        kmem_cache_destroy(dax_cache);

        return rc;
@@ -639,7 +633,6 @@ static int dax_fs_init(void)
 static void dax_fs_exit(void)
 {
        kern_unmount(dax_mnt);
-       unregister_filesystem(&dax_fs_type);
        kmem_cache_destroy(dax_cache);
 }

Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?

[Al Viro]

On Sat, Mar 16, 2019 at 01:10:26PM -0700, Dan Williams wrote:
> On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         It's not user-mountable, kern_mount() doesn't care about
> > looking it up by name, so the only effect of having it registered
> > is having it visible in /proc/filesystems.
> >
> >         Do you need that for anything?  Because I would rather
> > avoid more of that voodoo...
> 
> It can die. It was mindless copy/paste from fs/blockdev.c and the
> "bdev" fs. The device-dax unit tests pass just fine with it removed.
> I'll send a formal patch with the following:

Acked-by: Al Viro <viro@zeniv.linux.org.uk>

Do you prefer it in your tree, or would you rather have it go through
vfs.git?

Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?

[Dan Williams]

On Sat, Mar 16, 2019 at 1:26 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Sat, Mar 16, 2019 at 01:10:26PM -0700, Dan Williams wrote:
> > On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > >         It's not user-mountable, kern_mount() doesn't care about
> > > looking it up by name, so the only effect of having it registered
> > > is having it visible in /proc/filesystems.
> > >
> > >         Do you need that for anything?  Because I would rather
> > > avoid more of that voodoo...
> >
> > It can die. It was mindless copy/paste from fs/blockdev.c and the
> > "bdev" fs. The device-dax unit tests pass just fine with it removed.
> > I'll send a formal patch with the following:
>
> Acked-by: Al Viro <viro@zeniv.linux.org.uk>
>
> Do you prefer it in your tree, or would you rather have it go through
> vfs.git?

vfs.git is fine. Patch inbound.