Re: [git pull] new mount API

[Andy Lutomirski <luto@amacapital.net>]

On Thu, Aug 23, 2018 at 3:31 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> new mount API series from Dave Howells
>
> To quote his cover letter,
>         Here are a set of patches to create a filesystem context prior to setting
>         up a new mount, populating it with the parsed options/binary data, creating
>         the superblock and then effecting the mount.  This is also used for remount
>         since much of the parsing stuff is common in many filesystems.
>
>         This allows namespaces and other information to be conveyed through the
>         mount procedure.
>
>         This also allows Miklós Szeredi's idea of doing:
>
>                 fd = fsopen("nfs");
>                 fsconfig(fd, FSCONFIG_SET_STRING, "option", "val", 0);
>                 fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
>                 mfd = fsmount(fd, MS_NODEV);
>                 move_mount(mfd, "", AT_FDCWD, "/mnt", MOVE_MOUNT_F_EMPTY_PATH);
>
>         that he presented at LSF-2017 to be implemented (see the relevant patches
>         in the series).
>
>         I didn't use netlink as that would make the core kernel depend on
>         CONFIG_NET and CONFIG_NETLINK and would introduce network namespacing
>         issues.
>
>         I've implemented filesystem context handling for procfs, nfs, mqueue,
>         cpuset, kernfs, sysfs, cgroup and afs filesystems.
>
>         Unconverted filesystems are handled by a legacy filesystem wrapper.
>
> One trivial conflict in fs/file_table.c:__fput(); resolved as
>         if (unlikely(mode & FMODE_NEED_UNMOUNT))
>                 dissolve_on_fput(mnt);
>         dput(dentry);
>         mntput(mnt);
> out:
>         file_free(file);
>

Has anything been done to ensure that the behavior when doing
FSCONFIG_CMD_CREATE against an already-mounted block device is
reasonable?