Re: [PATCH v2 0/4] fs: add immutable rootfs

[Askar Safin <safinaskar@gmail.com>]

Christian, important! Your patchset breaks userspace! (And I tested this.)

Christian Brauner <brauner@kernel.org>:
> Currently pivot_root() doesn't work on the real rootfs because it
> cannot be unmounted. Userspace has to do a recursive removal of the
> initramfs contents manually before continuing the boot.

listmount is buggy (see details below), but currently on a typical
Linux distro the bug is hidden. Your new nullfs patchset exposes the bug,
and now typical Linux configuration becomes buggy!

Look at this loop:
https://elixir.bootlin.com/linux/v6.19-rc5/source/fs/namespace.c#L5518 .

This loop is executed, when we call listmount on non-our namespace with
LSMT_ROOT.

As you can see, this loop finds mount, which is exactly one layer above
initial root mount. But why? What if our initial root mount was
overmounted multiple times?

What (in my opinion) is actually needed here is to find topmost overmount
of initial root mount. We know how to do this, we do this here:
https://elixir.bootlin.com/linux/v6.19-rc5/source/fs/namespace.c#L6096 .

Fortunately, current listmount code works in a typical configuration.
Usually we indeed overmount initramfs exactly one time.
So, listmount usually does the right thing.

But this nullfs patchset breaks listmount. Now on a typical distro
(we assume that initramfs implementations (i. e. dracut, etc) are not
yet changed to take advantage of nullfs) initial root mount (i. e. nullfs)
will be overmounted two times: initramfs and actual disk root fs.

So listmount with LSMT_ROOT in somebody's else namespace will return
initramfs instead of actual topmost root fs.

I think this listmount bug should be fixed before nullfs is applied to
mainline.

I tested listmount behavior I'm talking about. On both vfs.all (i. e. with
nullfs patches applied) and on some older vfs.git commit (without nullfs).

-- 
Askar Safin