Thread (2 messages) 2 messages, 2 authors, 2025-08-27

Re: [RFC][PATCH] switch do_new_mount_fc() to using fc_mount()

From: Paul Moore <paul@paul-moore.com>
Date: 2025-08-27 15:38:20
Also in: linux-fsdevel

On Tue, Aug 26, 2025 at 2:21 PM Al Viro [off-list ref] wrote:
[
This is on top of -rc3; if nobody objects, I'll insert that early in series
in viro/vfs.git#work.mount.  It has an impact for LSM folks - ->sb_kern_mount()
would be called without ->s_umount; nothing in-tree cares, but if you have
objections, yell now.
]
Thanks for the heads-up, I'm not aware of anyone currently
posting/working-on patches that would be dependent on this.
Prior to the call of do_new_mount_fc() the caller has just done successful
vfs_get_tree().  Then do_new_mount_fc() does several checks on resulting
superblock, and either does fc_drop_locked() and returns an error or
proceeds to unlock the superblock and call vfs_create_mount().

The thing is, there's no reason to delay that unlock + vfs_create_mount() -
the tests do not rely upon the state of ->s_umount and
        fc_drop_locked()
        put_fs_context()
is equivalent to
        unlock ->s_umount
        put_fs_context()

Doing vfs_create_mount() before the checks allows us to move vfs_get_tree()
from caller to do_new_mount_fc() and collapse it with vfs_create_mount()
into an fc_mount() call.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-- 
paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help