Skip to content

Mount writer count and read-only bind mounts (v5)

Dave Hansen lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest28 patches 12 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/28prepare for write access checks: collapse if()fs/namei.c fs/open.c+87 -701 reply
2/28r/o bind mount prepwork: move open_namei()'s vfs_create()fs/namei.c+20 -101 reply
3/28unlink: monitor i_nlinkdrivers/usb/core/inode.c fs/autofs/root.c fs/autofs4/root.c +25 more+84 -931 reply
4/28OCFS2 is screwyfs/libfs.c fs/ocfs2/namei.c include/linux/fs.h+20 -37 replies
5/28monitor zeroing of i_nlinkfs/autofs4/root.c fs/cifs/inode.c fs/ext3/namei.c +13 more+22 -230 replies
6/28reintroduce list of vfsmounts over superblockfs/namespace.c fs/super.c include/linux/fs.h +1 more+15 -02 replies
7/28Add vfsmount writer countfs/namespace.c fs/super.c include/linux/fs.h +1 more+142 -50 replies
8/28record when sb_writer_count elevated for inodefs/inode.c fs/libfs.c include/linux/fs.h+9 -10 replies
9/28kill open files traverse on remount rofs/file_table.c fs/super.c include/linux/fs.h+0 -280 replies
10/28increment sb writer count when nlink hits zerofs/libfs.c+1 -00 replies
11/28elevate writer count for chown and friendsfs/open.c+33 -50 replies
12/28elevate mnt writers for callers of vfs_mkdir()fs/namei.c fs/nfsd/nfs4recover.c+9 -00 replies
13/28elevate write count during entire ncp_ioctl()fs/ncpfs/ioctl.c+54 -10 replies
14/28sys_symlinkat() elevate write count around vfs_symlink()fs/namei.c+5 -00 replies
15/28elevate mount count for extended attributesfs/nfsd/nfs4proc.c fs/xattr.c+20 -10 replies
16/28sys_linkat(): elevate write count around vfs_link()fs/namei.c+5 -00 replies
17/28mount_is_safe(): add commentfs/namespace.c+4 -00 replies
18/28unix_find_other() elevate write count for touch_atime()net/unix/af_unix.c+12 -40 replies
19/28elevate write count over calls to vfs_rename()fs/namei.c fs/nfsd/vfs.c+24 -50 replies
20/28tricky: elevate write count files are open()edfs/file_table.c fs/namei.c ipc/mqueue.c+25 -50 replies
21/28elevate writer count for do_sys_truncate()fs/open.c+11 -50 replies
22/28elevate write count for do_utimes()fs/open.c+9 -40 replies
23/28elevate write count for do_sys_utime() and touch_atime()fs/inode.c fs/open.c+18 -70 replies
24/28sys_mknodat(): elevate write count for vfs_mknod/create()fs/namei.c fs/nfsd/vfs.c net/unix/af_unix.c+20 -00 replies
25/28elevate mnt writers for vfs_unlink() callersfs/namei.c ipc/mqueue.c+8 -10 replies
26/28do_rmdir(): elevate write countfs/namei.c+5 -00 replies
27/28elevate writer count for custom 'struct file'fs/hugetlbfs/inode.c mm/shmem.c mm/tiny-shmem.c +1 more+9 -02 replies
28/28honor r/w changes at do_remount() timefs/namespace.c fs/open.c+23 -30 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 00/28] Mount writer count and read-only bind mounts (v5)

Tries to incorporate comments from Al:
http://article.gmane.org/gmane.linux.kernel/421029

Quoted 2 lines · Al

b) figuring out what (if anything) should be done with propagation when we have shared subtrees... (not trivial at all)

Talked with Ram: Shared subtrees are about having identical views into the filesystem. Changing the mount permissions doesn't affect the view of the filesystem, so it should not be propagated.

The things that probably need the heaviest review in here are the i_nlink monitoring patch (including the inode state flag patches 03 and 06) and the new MNT_SB_WRITABLE flag (patch 05).

These are against 2.6.18-rc2-mm1. Does anybody have anything against them having some testing in -mm?

---

The following series implements read-only bind mounts. This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given mount. In this version, if there are writers on a superblock, the filesystem may not be remounted r/o. The same goes for MS_BIND mounts, and writers on a vfsmount.

This has a number of uses. It allows chroots to have parts of filesystems writable. It will be useful for containers in the future and is intended to replace patches that vserver has had out of the tree for several years. It allows security enhancement by making sure that parts of your filesystem read-only, when you don't want to have entire new filesystems mounted, or when you want atime selectively updated.

This set makes no attempt to keep the return codes for these r/o bind mounts the same as for a real r/o filesystem or device. It would require significantly more code and be quite a bit more invasive.

Using this feature requires two steps:

	mount --bind /source /dest
	mount -o remount,ro  /dest