Messages in this thread | | | From | Menglong Dong <> | Date | Tue, 25 May 2021 11:28:19 +0800 | Subject | Re: [PATCH 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs |
| |
On Tue, May 25, 2021 at 8:44 AM Luis Chamberlain <mcgrof@kernel.org> 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
| |