Skip to content

Commit 4727bd4

Browse files
Al Viropaniakin-aws
authored andcommitted
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
commit 250cf36 upstream. ... 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. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
1 parent 0965d85 commit 4727bd4

File tree

1 file changed

+1
-5
lines changed

1 file changed

+1
-5
lines changed

fs/namespace.c

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -662,12 +662,8 @@ int __legitimize_mnt(struct vfsmount *bastard, unsigned seq)
662662
smp_mb(); // see mntput_no_expire()
663663
if (likely(!read_seqretry(&mount_lock, seq)))
664664
return 0;
665-
if (bastard->mnt_flags & MNT_SYNC_UMOUNT) {
666-
mnt_add_count(mnt, -1);
667-
return 1;
668-
}
669665
lock_mount_hash();
670-
if (unlikely(bastard->mnt_flags & MNT_DOOMED)) {
666+
if (unlikely(bastard->mnt_flags & (MNT_SYNC_UMOUNT | MNT_DOOMED))) {
671667
mnt_add_count(mnt, -1);
672668
unlock_mount_hash();
673669
return 1;

0 commit comments

Comments
 (0)