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
