On Thu, Aug 23, 2018 at 3:31 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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?
