]> git.baikalelectronics.ru Git - kernel.git/commit
move mount_capable() further out
authorAl Viro <viro@zeniv.linux.org.uk>
Mon, 13 May 2019 16:57:22 +0000 (12:57 -0400)
committerAl Viro <viro@zeniv.linux.org.uk>
Sat, 25 May 2019 22:00:02 +0000 (18:00 -0400)
commit471db0e4027b2ae43b32c08fa293886797f4cc20
tree95e0457725a49ae8849f4e17014de6871b78cac3
parent9c8c220fbb5c2801f0222849795be7c03d7fe2b1
move mount_capable() further out

Call graph of vfs_get_tree():
vfs_fsconfig_locked() # neither kernmount, nor submount
do_new_mount() # neither kernmount, nor submount
fc_mount()
afs_mntpt_do_automount() # submount
mount_one_hugetlbfs() # kernmount
pid_ns_prepare_proc() # kernmount
mq_create_mount() # kernmount
vfs_kern_mount()
simple_pin_fs() # kernmount
vfs_submount() # submount
kern_mount() # kernmount
init_mount_tree()
btrfs_mount()
nfs_do_root_mount()

The first two need the check (unconditionally).
init_mount_tree() is setting rootfs up; any capability
checks make zero sense for that one.  And btrfs_mount()/
nfs_do_root_mount() have the checks already done in their
callers.

IOW, we can shift mount_capable() handling into
the two callers - one in the normal case of mount(2),
another - in fsconfig(2) handling of FSCONFIG_CMD_CREATE.
I.e. the syscalls that set a new filesystem up.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/fsopen.c
fs/namespace.c
fs/super.c