From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] move_mount(2): still breakage around new mount detection
Date: Mon, 5 May 2025 06:08:55 +0100 [thread overview]
Message-ID: <20250505050855.GE2023217@ZenIV> (raw)
In-Reply-To: <20250429051054.GP2023217@ZenIV>
On Tue, Apr 29, 2025 at 06:10:54AM +0100, Al Viro wrote:
> On Tue, Apr 29, 2025 at 05:03:58AM +0100, Al Viro wrote:
> > On Mon, Apr 28, 2025 at 07:53:18PM +0100, Al Viro wrote:
> >
> > > FWIW, I've a series of cleanups falling out of audit of struct mount
> > > handling; it's still growing, but I'll post the stable parts for review
> > > tonight or tomorrow...
> >
> > _Another_ fun one, this time around do_umount().
>
> ... and more, from 620c266f3949 "fhandle: relax open_by_handle_at()
> permission checks" - just what is protecting has_locked_children()
> use there? We are, after all, iterating through ->mnt_mounts -
> with no locks whatsoever. Not to mention the fun question regarding
> the result (including the bits sensitive to is_mounted()) remaining
> valid by the time you get through exportfs_decode_fh_raw() (and no,
> you can't hold any namespace_sem over it - no IO allowed under
> that, so we'll need to recheck after that point)...
FWIW, looking at do_move_mounts(): some of the tests look odd.
if (is_anon_ns(ns)) {
/*
* Ending up with two files referring to the root of the
* same anonymous mount namespace would cause an error
* as this would mean trying to move the same mount
* twice into the mount tree which would be rejected
* later. But be explicit about it right here.
*/
if ((is_anon_ns(p->mnt_ns) && ns == p->mnt_ns))
goto out;
Why are we checking is_anon_ns(p->mnt_ns) here? If ns is equal
to p->mnt_ns, we have just verified that is_anon_ns() is true for it;
if it is not, there's no point bothering with is_anon_ns() since
conjunction is false anyway. And it's not as if that comparison
had been unsafe to calculate if is_anon_ns(p->mnt_ns) is false...
Looks really really confusing - is there a typo somewhere? Why
not simply
if (is_anon_ns(ns)) {
/*
* Can't move the root of namespace into the same
* namespace. Reject that early.
*/
if (ns == p->mnt)
goto out;
What am I missing here?
Another odd thing: what's the point rejecting move of /foo/bar/baz/ beneath
/foo? What's wrong with doing that? _IF_ that's really intended, it needs
at least a comment spelling that out. TBH, for quite a while I'd been
staring at that wondering WTF do you duplicate the common check for target
not being a descendent of source, but with different error value. Until
spotting that the check is about _source_ being a descendent of target
rather than the other way round...
next prev parent reply other threads:[~2025-05-05 5:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 6:30 [RFC] move_mount(2): still breakage around new mount detection Al Viro
2025-04-28 7:03 ` Al Viro
2025-04-28 8:50 ` Christian Brauner
2025-04-28 18:53 ` Al Viro
2025-04-29 4:03 ` Al Viro
2025-04-29 5:10 ` Al Viro
2025-04-29 5:27 ` Al Viro
2025-04-29 8:21 ` Christian Brauner
2025-05-05 5:08 ` Al Viro [this message]
2025-05-05 14:20 ` Christian Brauner
2025-04-29 7:56 ` Christian Brauner
2025-04-29 12:27 ` Al Viro
2025-04-29 7:52 ` Christian Brauner
2025-05-08 5:56 ` more breakage there (was Re: [RFC] move_mount(2): still breakage around new mount detection) Al Viro
2025-05-08 19:59 ` Al Viro
2025-05-08 20:00 ` [PATCH 1/4] __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock Al Viro
2025-05-09 11:02 ` Christian Brauner
2025-05-08 20:01 ` [PATCH 2/4] do_umount(): add missing barrier before refcount checks in sync case Al Viro
2025-05-09 11:02 ` Christian Brauner
2025-05-08 20:02 ` [PATCH 3/4] do_move_mount(): don't leak MNTNS_PROPAGATING on failures Al Viro
2025-05-08 20:03 ` reproducer for "do_move_mount(): don't leak MNTNS_PROPAGATING on failures" Al Viro
2025-05-09 11:02 ` [PATCH 3/4] do_move_mount(): don't leak MNTNS_PROPAGATING on failures Christian Brauner
2025-05-13 11:03 ` Lai, Yi
2025-05-13 12:08 ` Al Viro
2025-05-13 14:33 ` Lai, Yi
2025-05-08 20:02 ` [PATCH 4/4] fix IS_MNT_PROPAGATING uses Al Viro
2025-05-08 20:04 ` reproducer for "fix IS_MNT_PROPAGATING uses" Al Viro
2025-05-09 11:01 ` [PATCH 4/4] fix IS_MNT_PROPAGATING uses Christian Brauner
2025-05-09 11:06 ` more breakage there (was Re: [RFC] move_mount(2): still breakage around new mount detection) Christian Brauner
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=20250505050855.GE2023217@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox