All of lore.kernel.org
 help / color / mirror / Atom feed
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...

  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 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.