From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-fsdevel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
"Lai, Yi" <yi1.lai@linux.intel.com>,
Tycho Andersen <tycho@tycho.pizza>,
Andrei Vagin <avagin@google.com>,
Pavel Tikhomirov <snorcht@gmail.com>
Subject: [PATCH 2/4] propagate_umount(): only surviving overmounts should be remounted
Date: Sat, 16 Aug 2025 00:34:50 +0100 [thread overview]
Message-ID: <20250815233450.GB2117906@ZenIV> (raw)
In-Reply-To: <20250815233316.GS222315@ZenIV>
... as the comments in reparent() clearly say. As it is, we reparent
*all* overmounts of the mounts being taken out, including those that
are taken out themselves. It's not only a potentially massive slowdown
(on a pathological setup we might end up with O(N^2) time for N mounts
being kicked out), it can end up with incorrect ->overmount in the
surviving mounts.
Fixes: f0d0ba19985d "Rewrite of propagate_umount()"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
fs/pnode.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/pnode.c b/fs/pnode.c
index 81f7599bdac4..1c789f88b3d2 100644
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -637,10 +637,11 @@ void propagate_umount(struct list_head *set)
}
// now to_umount consists of all acceptable candidates
- // deal with reparenting of remaining overmounts on those
+ // deal with reparenting of surviving overmounts on those
list_for_each_entry(m, &to_umount, mnt_list) {
- if (m->overmount)
- reparent(m->overmount);
+ struct mount *over = m->overmount;
+ if (over && !will_be_unmounted(over))
+ reparent(over);
}
// and fold them into the set
--
2.47.2
next prev parent reply other threads:[~2025-08-15 23:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 23:33 [PATCHES][RFC][CFT] mount fixes Al Viro
2025-08-15 23:34 ` [PATCH 1/4] fix the softlockups in attach_recursive_mnt() Al Viro
2025-08-19 10:18 ` Christian Brauner
2025-08-15 23:34 ` Al Viro [this message]
2025-08-19 10:19 ` [PATCH 2/4] propagate_umount(): only surviving overmounts should be remounted Christian Brauner
2025-08-15 23:35 ` [PATCH 3/4] use uniform permission checks for all mount propagation changes Al Viro
2025-08-16 18:28 ` Andrei Vagin
2025-08-19 4:44 ` Pavel Tikhomirov
2025-08-19 10:20 ` Christian Brauner
2025-08-15 23:36 ` [PATCH 4/4] change_mnt_propagation(): calculate propagation source only if we'll need it Al Viro
2025-08-19 10:20 ` Christian Brauner
2025-08-16 15:58 ` [PATCHES][RFC][CFT] mount fixes Al Viro
2025-08-19 16:12 ` [git pull] " Al Viro
2025-08-19 17:31 ` Linus Torvalds
2025-08-19 17:33 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250815233450.GB2117906@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=avagin@google.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=snorcht@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=tycho@tycho.pizza \
--cc=yi1.lai@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.