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... -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html