* [PATCH][RFC] __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
@ 2025-04-27 19:50 Al Viro
2025-04-28 7:55 ` Christian Brauner
0 siblings, 1 reply; 2+ messages in thread
From: Al Viro @ 2025-04-27 19:50 UTC (permalink / raw)
To: linux-fsdevel; +Cc: Christian Brauner, Jan Kara, Linus Torvalds
[another catch from struct mount audit]
... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/namespace.c b/fs/namespace.c
index 98a5cd756e9a..eba4748388b1 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -790,12 +790,8 @@ int __legitimize_mnt(struct vfsmount *bastard, unsigned seq)
smp_mb(); // see mntput_no_expire()
if (likely(!read_seqretry(&mount_lock, seq)))
return 0;
- if (bastard->mnt_flags & MNT_SYNC_UMOUNT) {
- mnt_add_count(mnt, -1);
- return 1;
- }
lock_mount_hash();
- if (unlikely(bastard->mnt_flags & MNT_DOOMED)) {
+ if (unlikely(bastard->mnt_flags & (MNT_SYNC_UMOUNT | MNT_DOOMED))) {
mnt_add_count(mnt, -1);
unlock_mount_hash();
return 1;
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH][RFC] __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
2025-04-27 19:50 [PATCH][RFC] __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock Al Viro
@ 2025-04-28 7:55 ` Christian Brauner
0 siblings, 0 replies; 2+ messages in thread
From: Christian Brauner @ 2025-04-28 7:55 UTC (permalink / raw)
To: Al Viro; +Cc: linux-fsdevel, Jan Kara, Linus Torvalds
On Sun, Apr 27, 2025 at 08:50:02PM +0100, Al Viro wrote:
> [another catch from struct mount audit]
> ... or we risk stealing final mntput from sync umount - raising mnt_count
> after umount(2) has verified that victim is not busy, but before it
> has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
> that it's safe to quietly undo mnt_count increment and leaves dropping
> the reference to caller, where it'll be a full-blown mntput().
>
> Check under mount_lock is needed; leaving the current one done before
> taking that makes no sense - it's nowhere near common enough to bother
> with.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
Reviewed-by: Christian Brauner <brauner@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-04-28 7:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-27 19:50 [PATCH][RFC] __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock Al Viro
2025-04-28 7:55 ` Christian Brauner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox