From: Al Viro <viro@zeniv.linux.org.uk>
To: Klara Modin <klarasmodin@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [RFC][PATCH] btrfs_get_tree_subvol(): switch from fc_mount() to vfs_create_mount()
Date: Tue, 6 May 2025 20:33:05 +0100 [thread overview]
Message-ID: <20250506193305.GR2023217@ZenIV> (raw)
In-Reply-To: <usokd3dnditdgjf772khf76rwjczn3qfd2qtxgxyvmqxpf5wmb@yfb66jhpnwtd>
On Tue, May 06, 2025 at 08:58:59PM +0200, Klara Modin wrote:
> > OK, let's try to see what clone_private_mount() is unhappy about...
> > Could you try the following on top of -next + braino fix and see
> > what shows up? Another interesting thing, assuming you can get
> > to shell after overlayfs mount failure, would be /proc/self/mountinfo
> > contents and stat(1) output for upper path of your overlayfs mount...
>
> ret = vfs_get_tree(dup_fc);
> if (!ret) {
> ret = btrfs_reconfigure_for_mount(dup_fc);
> up_write(&dup_fc->root->d_sb->s_umount);
> }
> if (!ret)
> mnt = vfs_create_mount(fc);
> else
> mnt = ERR_PTR(ret);
> put_fs_context(dup_fc);
>
>
> I tried replacing fc with dup_fc in vfs_create_mount and it seems to
> work.
*blink*
OK, I'm a blind idiot - blind for not seeing the braino duplication,
idiot for not thinking to check if the same thing has happened
more than once.
Kudos for catching that. I still wonder what the hell got passed
to overlayfs, though - vfs_create_mount() should've hit
if (!fc->root)
return ERR_PTR(-EINVAL);
since fc->root definitely was NULL there. So we should've gotten
a failing btrfs mount; fine, but that does not explain the form
of breakage you are seeing on the overlayfs side... Actually...
is that mount attempted while still on initramfs? Because if
it is, we are running into a separate clone_private_mount()
bug.
There's nothing to prohibit an overlayfs mount with writable layer
being a subtree of initramfs; odd, but nothing inherently wrong
with that setup. And prior to that clone_private_mount() change
it used to be fine; we would get a private mount with root
pointing to subtree of initramfs and went on to use that.
We used to require the original mount to be in our namespace;
Christian's change added "... or root of anon namespace".
The order of checks went wrong, though. We check for "is
it an absolute root" *first* and treat that as a discriminator
between the new and old cases. It should be the other way
round - "is it in our namespace" should take precedence.
IOW,
if (!check_mount(...)) { // if it's not ours...
// ... it should be root...
if (mnt_has_parent(...))
fail
// ... of anon namespace...
if (!is_mounted(...) || !is_anon_ns(...))
fail
// ... and create no namespace loops -
// or no hidden references to namespaces, period
if (mnt_ns_loop(...)) // or, perhaps, if (mnt_ns_from_dentry(...))
fail
}
Anyway, that's a separate issue.
next prev parent reply other threads:[~2025-05-06 19:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 3:03 [RFC][PATCH] btrfs_get_tree_subvol(): switch from fc_mount() to vfs_create_mount() Al Viro
2025-05-05 17:58 ` David Sterba
2025-05-05 19:21 ` Al Viro
2025-05-06 13:36 ` Klara Modin
2025-05-06 16:43 ` Al Viro
2025-05-06 16:48 ` Klara Modin
2025-05-06 17:25 ` Al Viro
2025-05-06 17:47 ` Klara Modin
2025-05-06 17:51 ` Al Viro
2025-05-06 17:54 ` Klara Modin
2025-05-06 18:16 ` Al Viro
2025-05-06 18:34 ` Klara Modin
2025-05-06 19:05 ` Al Viro
2025-05-06 19:20 ` Klara Modin
2025-05-06 19:48 ` Al Viro
2025-05-06 18:58 ` Klara Modin
2025-05-06 19:33 ` Al Viro [this message]
2025-05-06 19:44 ` Klara Modin
2025-05-06 19:34 ` [PATCH v2] " Al Viro
2025-05-06 19:52 ` Klara Modin
2025-05-06 20:00 ` Al Viro
2025-05-06 19:58 ` [PATCH v3] " Al Viro
2025-05-08 9:29 ` Qu Wenruo
2025-06-03 7:59 ` David Sterba
2025-06-03 9:23 ` Qu Wenruo
2025-06-03 19:38 ` David Sterba
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=20250506193305.GR2023217@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=klarasmodin@gmail.com \
--cc=linux-btrfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).