Thread (40 messages) 40 messages, 9 authors, 2026-07-24

Re: [RFC] Null Namespaces

From: Christian Brauner <brauner@kernel.org>
Date: 2026-07-24 08:04:29
Also in: linux-arch, linux-fsdevel, lkml

quoted
quoted
For my FD_FAILFS_ROOT proposal it would be enough if we make failfs
SB_KERNMOUNT which means it's logically distinct from every mount
namespace. I think that might be the right thing to do. I need to spend
one or more brain cycles on this though.
I had to take a long drive on Sunday and I kept thinking about both
FD_NULLFS_ROOT and FD_FAILFS_ROOT and ofc there are some things to
consider/discuss.

I think the straightforward solution to FD_NULLFS_ROOT would be to just:

- make it always available
- refer to the caller's mount namespace nullfs
- work with fchroot()/fchdir()

So I considered two chroot() use-cases for the sake of simplicity:

(1) You want to isolate yourself for the sake of lookup

(2) You want to isolate yourself to assemble a "private mount tree" but
    not really be in a separate namespace (very odd use-case... but it
    helps to make a point).

The problem with this approach is that everyone who chroots into the
nullfs root would suffer from the problem that any mount on top of it is
still visible. So that kinda makes it pointless for both (1) and (2).

Also all mounts that someone else would do would also be visible
allowing multiple chroot()ers to affect each others state. That also
would somewhat defeat the purpose of the chroot(). So I'm not convinced
this is what we should do.
After some contemplation and a long place flight: are we talking about
nullfs or failfs?  Because I would expect that it's entirely
nullfs
impossible to mount anything on top of failfs.  So failfs would be
useless for #2 but would still solve #1.
Yes, failfs can't be mounted on at all.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help