Re: [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount [ver #8]
From: Arnd Bergmann
Date: Mon Jun 04 2018 - 11:05:22 EST
On Fri, May 25, 2018 at 2:07 AM, David Howells <dhowells@xxxxxxxxxx> 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