I've created a git tree with the following mounts related stuff:
- read-only bind mounts
- /proc/<pid>/mountinfo
- unprivileged mounts
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfsstuff.git master
I guess, giving these a spin in linux-next wouldn't hurt?
Thanks,
Miklos
Dave Hansen (33):
reiserfs: eliminate private use of struct file in xattr
hppfs pass vfsmount to dentry_open()
check for null vfsmount in dentry_open()
fix up new filp allocators
do namei_flags calculation inside open_namei()
merge open_namei() and do_filp_open()
r/o bind mounts: stub functions
r/o bind mounts: create helper to drop file write access
r/o bind mounts: drop write during emergency remount
r/o bind mounts: elevate write count for vfs_rmdir()
r/o bind mounts: elevate write count for callers of vfs_mkdir()
r/o bind mounts: elevate mnt_writers for unlink callers
r/o bind mounts: elevate write count for xattr_permission() callers
r/o bind mounts: elevate write count for ncp_ioctl()
r/o bind mounts: write counts for time functions
r/o bind mounts: elevate write count for do_utimes()
r/o bind mounts: write count for file_update_time()
r/o bind mounts: write counts for link/symlink
r/o bind mounts: elevate write count for ioctls()
r/o bind mounts: elevate write count for open()s
r/o bind mounts: get write access for vfs_rename() callers
r/o bind mounts: elevate write count for chmod/chown callers
r/o bind mounts: write counts for truncate()
r/o bind mounts: elevate count for xfs timestamp updates
r/o bind mounts: make access() use new r/o helper
r/o bind mounts: check mnt instead of superblock directly
r/o bind mounts: get callers of vfs_mknod/create()
r/o bind mounts: track numbers of writers to mounts
r/o bind mounts: honor mount writer counts at remount
r/o bind mounts: debugging for missed calls
ehea-fix
fixes for missed struct paths from akpm
Revert "ehea-fix"
Miklos Szeredi (10):
unprivileged mounts: add user mounts to the kernel
unprivileged mounts: allow unprivileged umount
unprivileged mounts: propagate error values from clone_mnt
unprivileged mounts: account user mounts
unprivileged mounts: allow unprivileged bind mounts
unprivileged mounts: allow unprivileged mounts
unprivileged mounts: add sysctl tunable for "safe" property
unprivileged mounts: make fuse safe
unprivileged mounts: propagation: inherit owner from parent
unprivileged mounts: add "no submounts" flag
Ram Pai (1):
vfs-create-proc-pid-mountinfo
Hi Miklos,
On Tue, 19 Feb 2008 14:32:28 +0100 Miklos Szeredi <[email protected]> wrote:
>
> I've created a git tree with the following mounts related stuff:
>
> - read-only bind mounts
> - /proc/<pid>/mountinfo
> - unprivileged mounts
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfsstuff.git master
>
> I guess, giving these a spin in linux-next wouldn't hurt?
I don't think this is what we want to use linux-next for. Linux-next is
really a place for stuff that will pretty clearly go into the next kernel
release i.e. 2.6.26 right now. If you want to experiment on things for
beyond that timeframe, then a snapshot of linux-next may be a good base.
I will take them when they reach the appropriate subsystem tree and are
ready for integration.
--
Cheers,
Stephen Rothwell [email protected]
On Thu, Feb 21, 2008 at 01:13:48AM +1100, Stephen Rothwell wrote:
> Hi Miklos,
>
> On Tue, 19 Feb 2008 14:32:28 +0100 Miklos Szeredi <[email protected]> wrote:
> >
> > I've created a git tree with the following mounts related stuff:
> >
> > - read-only bind mounts
> > - /proc/<pid>/mountinfo
> > - unprivileged mounts
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfsstuff.git master
> >
> > I guess, giving these a spin in linux-next wouldn't hurt?
>
> I don't think this is what we want to use linux-next for. Linux-next is
> really a place for stuff that will pretty clearly go into the next kernel
> release i.e. 2.6.26 right now. If you want to experiment on things for
> beyond that timeframe, then a snapshot of linux-next may be a good base.
> I will take them when they reach the appropriate subsystem tree and are
> ready for integration.
FWIW, I must apologize for delay with getting the damn tree open on
kernel.org ;-/ The last couple of weeks had been Not Fun(tm) in a
lot of respects.
Hopefully I'll finish putting the damn thing into publishable shape by
tomorrow. As for the stuff mentioned above... ro-bind series - definitely
yes, mountinfo - IMO needs a sane discussion of what and how should be shown
wrt propagation state, unprivileged mounts - in the "need to finish reviewing"
pile.