From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f65.google.com ([209.85.215.65]:42178 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753410AbeFDPFM (ORCPT ); Mon, 4 Jun 2018 11:05:12 -0400 MIME-Version: 1.0 In-Reply-To: <152720686035.9073.17015443936296474540.stgit@warthog.procyon.org.uk> References: <152720672288.9073.9868393448836301272.stgit@warthog.procyon.org.uk> <152720686035.9073.17015443936296474540.stgit@warthog.procyon.org.uk> From: Arnd Bergmann Date: Mon, 4 Jun 2018 17:05:09 +0200 Message-ID: Subject: Re: [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount [ver #8] To: David Howells Cc: Al Viro , Linux FS-devel Mailing List , linux-afs@lists.infradead.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, May 25, 2018 at 2:07 AM, David Howells 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