Re: [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount [ver #8]

From: Arnd Bergmann <arnd@arndb.de>
To: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-afs@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount [ver #8]
Date: Mon, 4 Jun 2018 17:05:09 +0200	[thread overview]
Message-ID: <CAK8P3a1QMrvMqLdg6OxKDSXz2wEceVMJ2-S9tJZETzk5oFcTCw@mail.gmail.com> (raw)
In-Reply-To: <152720686035.9073.17015443936296474540.stgit@warthog.procyon.org.uk>

On Fri, May 25, 2018 at 2:07 AM, David Howells <dhowells@redhat.com> wrote:
> Provide a system call by which a filesystem opened with fsopen() and
> configured by a series of writes can be mounted:
>
>         int ret = fsmount(int fsfd, int dfd, const char *path,
>                           unsigned int at_flags, unsigned int flags);
>

> +/*
> + * Create a kernel mount representation for a new, prepared superblock
> + * (specified by fs_fd) and attach to an O_PATH-class file descriptor.
> + */
> +SYSCALL_DEFINE5(fsmount, int, fs_fd, unsigned int, flags, unsigned int, ms_flags,
> +               void *, spare_4, void *, spare_5)

> +++ b/include/linux/syscalls.h
> @@ -898,6 +898,8 @@ asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
>                           unsigned mask, struct statx __user *buffer);
>  asmlinkage long sys_fsopen(const char *fs_name, unsigned int flags,
>                            void *reserved3, void *reserved4, void *reserved5);
> +asmlinkage long sys_fsmount(int fsfd, int dfd, const char *path, unsigned int at_flags,
> +                           unsigned int flags);
>

The prototype in the header doesn't match the one in the implementation,
which should cause a compile-time error, at least if syscalls.h is included
in namespace.c

Do you have a particular use case in mind for the spare_4/spare_5 arguments?
If not, we can probably skip them. If we end up needing them after all, we can
always add a new syscall entry point, or use one of the flag bits to
decide whether
the additional arguments are valid or not.

> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -435,3 +435,4 @@ COND_SYSCALL(setuid16);
>
>  /* fd-based mount */
>  COND_SYSCALL(sys_fsopen);
> +COND_SYSCALL(sys_fsmount);

This should only be needed if the syscall is optional, which it doesn't
seem to be (same for the other ones here).

       Arnd