On Tue, May 06, 2025 at 09:20:47PM +0200, Klara Modin wrote: > I then get: > > [ 0.881616] absolute root > [ 0.881618] our namespace, at that OK, so that's a combination of braino (times 2) in that patch with quiet regression in clone_private_mount() from back in January. Reposted with fixes folded in and yes, you are absolutely correct about the second 'fc' instead of 'dup_fc' in there. As for the clone_private_mount() issues... Christian has taught it to allow roots of anon namespaces in addition to mounts in our namespace, but did the tests in wrong order. It's not a rare pattern - "do something to mount in our namespace or the root of anon one" and for things like move_mount() we absolutely do *not* want to allow it for root of our namespace, so there this logics is fine - first split on whether it has a parent, then for parented ones require the namespace to be ours and for roots - require it to be anon. In case of clone_private_mount(), though, there's nothing wrong with "clone me a subtree of absolute root", so it has to be done other way round - check if it's ours first, then in "not ours" case check that it's a root of anon namespace. Failing btrfs mount has ended up with upper layer pathname pointing to initramfs directory where btrfs would've been mounted, which had walked into that corner case. In your case the problem has already happened by that point, but on a setup a-la X Terminal it would cause trouble...
