From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [BUG][RFC] broken use of __lookup_mnt() in path_overmounted()
Date: Thu, 19 Jun 2025 03:35:19 +0100 [thread overview]
Message-ID: <20250619023519.GT1880847@ZenIV> (raw)
In-Reply-To: <20250602-zugeneigt-abgepfiffen-c041e047f96e@brauner>
On Mon, Jun 02, 2025 at 11:17:25AM +0200, Christian Brauner wrote:
> Fwiw, I have pointed this out in one of my really early submission of
> this work and had asked whether we generally want the same check. That's
> also why I added the shadow-mount check into the automount path because
> that could be used for that sort of issue to afair but my memory is
> fuzzy here.
Actually, the check in do_move_mount() is too early. Look:
(after having made sure . is on a private mount)
mount -t tmpfs none A
mkdir A/x
mount --make-shared A
mount --bind A/x B
mount --make-slave B
mount -t tmpfs other A/x
umount B
... and now move_mount() B beneath A/x. See what happens? We get one
secondary copy, attached on top of the root of primary. _After_ we'd
entered attach_recursive_mnt(), so all checks in do_move_mount() have
nothing to catch - yet. So we end up with that secondary being side-by-side
with the "other" tmpfs...
The unpleasant part is that we'll need to backport that stuff, so it
has to be done _before_ the do_move_mount()/attach_recursive_mnt()
cleanups ;-/
Once the side-by-side thing is eliminated, we can (and IMO should) add
mnt->mnt_overmount pointing to whatever's mounted on top of root of
mnt (NULL if nothing is). That simplifies quite a few things, including
the prevention of side-by-side shite, but we can't do it first, more's
the pity...
Hell knows, maybe MNT_OVERMOUNTED as the first step would be doable -
it would allow for simpler (and lower-overhead) intermediate step
before the introduction of ->mnt_overmount and further simplifications...
prev parent reply other threads:[~2025-06-19 2:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-31 20:57 [BUG][RFC] broken use of __lookup_mnt() in path_overmounted() Al Viro
2025-06-01 17:40 ` Al Viro
2025-06-02 9:17 ` Christian Brauner
2025-06-19 2:35 ` Al Viro [this message]
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=20250619023519.GT1880847@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/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.