From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933327AbdCLCNR (ORCPT ); Sat, 11 Mar 2017 21:13:17 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:57532 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753782AbdCLCNM (ORCPT ); Sat, 11 Mar 2017 21:13:12 -0500 Date: Sun, 12 Mar 2017 02:13:02 +0000 From: Al Viro To: Alexey Gladkov Cc: Linux Kernel Mailing List , Linux API , "Kirill A. Shutemov" , Vasiliy Kulikov , "Eric W. Biederman" , Oleg Nesterov , Pavel Emelyanov , James Bottomley Subject: Re: [RFC] Add option to mount only a pids subset Message-ID: <20170312021257.GP29622@ZenIV.linux.org.uk> References: <20170221145746.GA31914@redhat.com> <20170306230515.GA3453@comp-core-i7-2640m-0182e6> <20170312015430.GO29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170312015430.GO29622@ZenIV.linux.org.uk> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 12, 2017 at 01:54:38AM +0000, Al Viro wrote: > On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote: > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 83de8b6..5bd1b84 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -1759,6 +1759,8 @@ struct super_operations { > > int (*thaw_super) (struct super_block *); > > int (*unfreeze_fs) (struct super_block *); > > int (*statfs) (struct dentry *, struct kstatfs *); > > + int (*getattr_fs) (struct vfsmount *, struct dentry *, struct kstat *); > > + int (*mount_fs) (struct vfsmount *, int *, char *); > > int (*remount_fs) (struct super_block *, int *, char *); > > void (*umount_begin) (struct super_block *); > > > > diff --git a/include/linux/mount.h b/include/linux/mount.h > > index 1172cce..4bd364e 100644 > > --- a/include/linux/mount.h > > +++ b/include/linux/mount.h > > @@ -67,6 +67,7 @@ struct vfsmount { > > struct dentry *mnt_root; /* root of the mounted tree */ > > struct super_block *mnt_sb; /* pointer to superblock */ > > int mnt_flags; > > + void *fs_data; /* fs-specific data */ > > No. This is really asking for trouble - you *can't* hang > fs-specific data structures off vfsmount. Lifetimes make no > sense whatsoever. > > BTW, your patch leaks supreblock reference on failure, and > is kludgy as hell wrt to what it's doing in procfs itself, but > that's secondary - the quoted part is enough for a hard NAK on > architectural grounds. Don't go there. PS: AFAICS, simple mount --bind of your pid-only mount will suddenly expose the full thing. And as for the lifetimes making no sense... note that you are simply not freeing these structures of yours. Try to handle that and you'll get a serious PITA all over the place. What are you trying to achieve, anyway? Why not add a second vfsmount pointer per pid_namespace and make it initialized on demand, at the first attempt of no-pid mount? Just have a separate no-pid instance created for those namespaces where it had been asked for, with separate superblock and dentry tree not containing anything other that pid-only parts + self + thread-self... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] Add option to mount only a pids subset Date: Sun, 12 Mar 2017 02:13:02 +0000 Message-ID: <20170312021257.GP29622@ZenIV.linux.org.uk> References: <20170221145746.GA31914@redhat.com> <20170306230515.GA3453@comp-core-i7-2640m-0182e6> <20170312015430.GO29622@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170312015430.GO29622-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexey Gladkov Cc: Linux Kernel Mailing List , Linux API , "Kirill A. Shutemov" , Vasiliy Kulikov , "Eric W. Biederman" , Oleg Nesterov , Pavel Emelyanov , James Bottomley List-Id: linux-api@vger.kernel.org On Sun, Mar 12, 2017 at 01:54:38AM +0000, Al Viro wrote: > On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote: > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 83de8b6..5bd1b84 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -1759,6 +1759,8 @@ struct super_operations { > > int (*thaw_super) (struct super_block *); > > int (*unfreeze_fs) (struct super_block *); > > int (*statfs) (struct dentry *, struct kstatfs *); > > + int (*getattr_fs) (struct vfsmount *, struct dentry *, struct kstat *); > > + int (*mount_fs) (struct vfsmount *, int *, char *); > > int (*remount_fs) (struct super_block *, int *, char *); > > void (*umount_begin) (struct super_block *); > > > > diff --git a/include/linux/mount.h b/include/linux/mount.h > > index 1172cce..4bd364e 100644 > > --- a/include/linux/mount.h > > +++ b/include/linux/mount.h > > @@ -67,6 +67,7 @@ struct vfsmount { > > struct dentry *mnt_root; /* root of the mounted tree */ > > struct super_block *mnt_sb; /* pointer to superblock */ > > int mnt_flags; > > + void *fs_data; /* fs-specific data */ > > No. This is really asking for trouble - you *can't* hang > fs-specific data structures off vfsmount. Lifetimes make no > sense whatsoever. > > BTW, your patch leaks supreblock reference on failure, and > is kludgy as hell wrt to what it's doing in procfs itself, but > that's secondary - the quoted part is enough for a hard NAK on > architectural grounds. Don't go there. PS: AFAICS, simple mount --bind of your pid-only mount will suddenly expose the full thing. And as for the lifetimes making no sense... note that you are simply not freeing these structures of yours. Try to handle that and you'll get a serious PITA all over the place. What are you trying to achieve, anyway? Why not add a second vfsmount pointer per pid_namespace and make it initialized on demand, at the first attempt of no-pid mount? Just have a separate no-pid instance created for those namespaces where it had been asked for, with separate superblock and dentry tree not containing anything other that pid-only parts + self + thread-self...