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

Paul Moore paul at paul-moore.com
Wed Aug 27 15:38:07 UTC 2025


On Tue, Aug 26, 2025 at 2:21 PM Al Viro <viro at zeniv.linux.org.uk> 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 at zeniv.linux.org.uk>

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list