Re: [PATCH 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs

[Menglong Dong]

On Tue, May 25, 2021 at 8:44 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
>
> Cc'ing Josh as I think he might be interested in this.
>
......
>
> I think you can clarify this a bit more with:
>
>   If using container platforms such as Docker, upon initialization it
>   wants to use pivot_root() so that currently mounted devices do not
>   propagate to containers. An example of value in this is that
>   a USB device connected prior to the creation of a containers on the
>   host gets disconnected after a container is created; if the
>   USB device was mounted on containers, but already removed and
>   umounted on the host, the mount point will not go away untill all
>   containers unmount the USB device.

Thanks! It's really difficult for me to organize these words.

>
> So remind me.. so it would seem that if the rootfs uses a ramfs (initrd)
> that pivot_root works just fine. Why is that? Did someone add support
> for that? Has that always been the case that it works? If not, was it a
> consequence of how ramfs (initrd) works?
>
> And finally, why can't we share the same mechanism used for ramfs
> (initrd) for initramfs (tmpfs)?

In fact, initrd is totally different from initramfs. Initrd is not using
ramfs, it actually is a block fs, which is mounted on the first mount.
And initramfs can use ramfs or tmpfs.

During pivot_root, the mount of the root will be unmounted from its parent
mount. Initrd or block device fs has a parent mount, which is the first mount.
However, initramfs doesn't has a parent mount, because the first mount is
actually the root, which cpio is unpacked to.

The first mount is used by init_task, and I think it can't be unmounted,
because it is used by the kernel.

So the primary cause that pivot_root doesn't support is that it use
the first mount as its root.

>
> > What's more, after this patch, 'rootflags' in boot cmd is supported
> > by initramfs. Therefore, users can set the size of tmpfs with
> > 'rootflags=size=1024M'.
>
> Why is that exactly?

During the mount of user_mount, I passed root_mountflags and root_mount_data
to do_mount_root(), which make 'rootflags' works for 'user root'.

> > +
> > +struct fs_user_root {
> > +    bool (*enabled)(void);
> > +    char *dev_name;
>
> What's the point of dev_name if its never set?

Seems it's better to make it be set, I'll do it.


>
> Might be a good place to document that we do this so folks can
> pivot_root on rootfs, and why that is desirable (mentioned above on the
> commit log edits I suggested). Otherwise I don't think its easy for a
> reader of the code to understand why we are doing all this work.
>

Ok, sounds nice!

>
> Is anything extra needed on shutdown / reboot?
>

I'm not sure, seems no. The way I create 'user root' is exactly the same
as a block root fs does.

Thanks!
Menglong Dong