[v6,2/2] init/do_mounts.c: create second mount for initramfs

Commit Message

Menglong Dong June 5, 2021, 3:44 a.m. UTC

From: Menglong Dong <[e-mail]>

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 until all
containers unmount the USB device.

Another reason for container platforms such as Docker to use pivot_root
is that upon initialization the net-namspace is mounted under
/var/run/docker/netns/ on the host by dockerd. Without pivot_root
Docker must either wait to create the network namespace prior to
the creation of containers or simply deal with leaking this to each
container.

pivot_root is supported if the rootfs is a initrd or block device, but
it's not supported if the rootfs uses an initramfs (tmpfs). This means
container platforms today must resort to using block devices if
they want to pivot_root from the rootfs. A workaround to use chroot()
is not a clean viable option given every container will have a
duplicate of every mount point on the host.

In order to support using container platforms such as Docker on
all the supported rootfs types we must extend Linux to support
pivot_root on initramfs as well. This patch does the work to do
just that.

pivot_root will unmount the mount of the rootfs from its parent mount
and mount the new root to it. However, when it comes to initramfs, it
donesn't work, because the root filesystem has not parent mount, which
makes initramfs not supported by pivot_root.

In order to make pivot_root supported on initramfs, we create a second
mount with type of rootfs before unpacking cpio, and change root to
this mount after unpacking.

While mounting the second rootfs, 'rootflags' is passed, and it means
that we can set options for the mount of rootfs in boot cmd now.
For example, the size of tmpfs can be set with 'rootflags=size=1024M'.

Signed-off-by: Menglong Dong <[e-mail]>
---
 init/do_mounts.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 init/do_mounts.h | 17 ++++++++++++++++-
 init/initramfs.c |  8 ++++++++
 usr/Kconfig      | 10 ++++++++++
 4 files changed, 78 insertions(+), 1 deletion(-)

Comments

Christian Brauner June 5, 2021, 11:50 a.m. UTC | #1

On Sat, Jun 05, 2021 at 11:44:47AM +0800, [e-mail] wrote:
> From: Menglong Dong <[e-mail]>
> 
> 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 until all
> containers unmount the USB device.
> 
> Another reason for container platforms such as Docker to use pivot_root
> is that upon initialization the net-namspace is mounted under
> /var/run/docker/netns/ on the host by dockerd. Without pivot_root
> Docker must either wait to create the network namespace prior to
> the creation of containers or simply deal with leaking this to each
> container.
> 
> pivot_root is supported if the rootfs is a initrd or block device, but
> it's not supported if the rootfs uses an initramfs (tmpfs). This means
> container platforms today must resort to using block devices if
> they want to pivot_root from the rootfs. A workaround to use chroot()
> is not a clean viable option given every container will have a
> duplicate of every mount point on the host.
> 
> In order to support using container platforms such as Docker on
> all the supported rootfs types we must extend Linux to support
> pivot_root on initramfs as well. This patch does the work to do
> just that.
> 
> pivot_root will unmount the mount of the rootfs from its parent mount
> and mount the new root to it. However, when it comes to initramfs, it
> donesn't work, because the root filesystem has not parent mount, which
> makes initramfs not supported by pivot_root.
> 
> In order to make pivot_root supported on initramfs, we create a second
> mount with type of rootfs before unpacking cpio, and change root to
> this mount after unpacking.
> 
> While mounting the second rootfs, 'rootflags' is passed, and it means
> that we can set options for the mount of rootfs in boot cmd now.
> For example, the size of tmpfs can be set with 'rootflags=size=1024M'.
> 
> Signed-off-by: Menglong Dong <[e-mail]>
> ---
>  init/do_mounts.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  init/do_mounts.h | 17 ++++++++++++++++-
>  init/initramfs.c |  8 ++++++++
>  usr/Kconfig      | 10 ++++++++++
>  4 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index a78e44ee6adb..715bdaa89b81 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -618,6 +618,49 @@ void __init prepare_namespace(void)
>  }
>  
>  static bool is_tmpfs;
> +#ifdef CONFIG_INITRAMFS_MOUNT
> +
> +/*
> + * Give systems running from the initramfs and making use of pivot_root a
> + * proper mount so it can be umounted during pivot_root.
> + */
> +int __init prepare_mount_rootfs(void)
> +{
> +	char *rootfs = "ramfs";
> +
> +	if (is_tmpfs)
> +		rootfs = "tmpfs";
> +
> +	return do_mount_root(rootfs, rootfs,
> +			     root_mountflags & ~MS_RDONLY,
> +			     root_mount_data);
> +}
> +
> +/*
> + * Revert to previous mount by chdir to '/' and unmounting the second
> + * mount.
> + */
> +void __init revert_mount_rootfs(void)
> +{
> +	init_chdir("/");
> +	init_umount(".", MNT_DETACH);
> +}
> +
> +/*
> + * Change root to the new rootfs that mounted in prepare_mount_rootfs()
> + * if cpio is unpacked successfully and 'ramdisk_execute_command' exist.
> + */
> +void __init finish_mount_rootfs(void)
> +{
> +	init_mount(".", "/", NULL, MS_MOVE, NULL);
> +	if (likely(ramdisk_exec_exist()))
> +		init_chroot(".");
> +	else
> +		revert_mount_rootfs();
> +}
> +
> +#define rootfs_init_fs_context ramfs_init_fs_context

Sorry, I think we're nearly there. What's the rationale for using ramfs
when unconditionally when a separate mount for initramfs is requested?
Meaning, why do we need this define at all?

> +#else
>  static int rootfs_init_fs_context(struct fs_context *fc)
>  {
>  	if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
> @@ -625,6 +668,7 @@ static int rootfs_init_fs_context(struct fs_context *fc)
>  
>  	return ramfs_init_fs_context(fc);
>  }
> +#endif
>  
>  struct file_system_type rootfs_fs_type = {
>  	.name		= "rootfs",
> diff --git a/init/do_mounts.h b/init/do_mounts.h
> index 7a29ac3e427b..ae4ab306caa9 100644
> --- a/init/do_mounts.h
> +++ b/init/do_mounts.h
> @@ -10,9 +10,24 @@
>  #include <linux/root_dev.h>
>  #include <linux/init_syscalls.h>
>  
> +extern int root_mountflags;
> +
>  void  mount_block_root(char *name, int flags);
>  void  mount_root(void);
> -extern int root_mountflags;
> +
> +#ifdef CONFIG_INITRAMFS_MOUNT
> +
> +int  prepare_mount_rootfs(void);
> +void finish_mount_rootfs(void);
> +void revert_mount_rootfs(void);
> +
> +#else
> +
> +static inline int  prepare_mount_rootfs(void) { return 0; }
> +static inline void finish_mount_rootfs(void) { }
> +static inline void revert_mount_rootfs(void) { }
> +
> +#endif
>  
>  static inline __init int create_dev(char *name, dev_t dev)
>  {
> diff --git a/init/initramfs.c b/init/initramfs.c
> index af27abc59643..1833de3cf04e 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -16,6 +16,8 @@
>  #include <linux/namei.h>
>  #include <linux/init_syscalls.h>
>  
> +#include "do_mounts.h"
> +
>  static ssize_t __init xwrite(struct file *file, const char *p, size_t count,
>  		loff_t *pos)
>  {
> @@ -682,13 +684,19 @@ static void __init do_populate_rootfs(void *unused, async_cookie_t cookie)
>  	else
>  		printk(KERN_INFO "Unpacking initramfs...\n");
>  
> +	if (prepare_mount_rootfs())
> +		panic("Failed to mount rootfs");
> +
>  	err = unpack_to_rootfs((char *)initrd_start, initrd_end - initrd_start);
>  	if (err) {
> +		revert_mount_rootfs();
>  #ifdef CONFIG_BLK_DEV_RAM
>  		populate_initrd_image(err);
>  #else
>  		printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
>  #endif
> +	} else {
> +		finish_mount_rootfs();
>  	}
>  
>  done:
> diff --git a/usr/Kconfig b/usr/Kconfig
> index 8bbcf699fe3b..4f6ac12eafe9 100644
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -52,6 +52,16 @@ config INITRAMFS_ROOT_GID
>  
>  	  If you are not sure, leave it set to "0".
>  
> +config INITRAMFS_MOUNT
> +	bool "Create second mount to make pivot_root() supported"
> +	default y
> +	help
> +	  Before unpacking cpio, create a second mount and make it become
> +	  the root filesystem. Therefore, initramfs will be supported by
> +	  pivot_root().
> +
> +	  If container platforms is used with initramfs, say Y.
> +
>  config RD_GZIP
>  	bool "Support initial ramdisk/ramfs compressed using gzip"
>  	default y
> -- 
> 2.32.0.rc0
>

Menglong Dong June 5, 2021, 2:47 p.m. UTC | #2

Hello,

On Sat, Jun 5, 2021 at 7:50 PM Christian Brauner
<[e-mail]> wrote:
>
> On Sat, Jun 05, 2021 at 11:44:47AM +0800, [e-mail] wrote:
> > From: Menglong Dong <[e-mail]>
> >
> > 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 until all
> > containers unmount the USB device.
> >
> > Another reason for container platforms such as Docker to use pivot_root
> > is that upon initialization the net-namspace is mounted under
> > /var/run/docker/netns/ on the host by dockerd. Without pivot_root
> > Docker must either wait to create the network namespace prior to
> > the creation of containers or simply deal with leaking this to each
> > container.
> >
> > pivot_root is supported if the rootfs is a initrd or block device, but
> > it's not supported if the rootfs uses an initramfs (tmpfs). This means
> > container platforms today must resort to using block devices if
> > they want to pivot_root from the rootfs. A workaround to use chroot()
> > is not a clean viable option given every container will have a
> > duplicate of every mount point on the host.
> >
> > In order to support using container platforms such as Docker on
> > all the supported rootfs types we must extend Linux to support
> > pivot_root on initramfs as well. This patch does the work to do
> > just that.
> >
> > pivot_root will unmount the mount of the rootfs from its parent mount
> > and mount the new root to it. However, when it comes to initramfs, it
> > donesn't work, because the root filesystem has not parent mount, which
> > makes initramfs not supported by pivot_root.
> >
> > In order to make pivot_root supported on initramfs, we create a second
> > mount with type of rootfs before unpacking cpio, and change root to
> > this mount after unpacking.
> >
> > While mounting the second rootfs, 'rootflags' is passed, and it means
> > that we can set options for the mount of rootfs in boot cmd now.
> > For example, the size of tmpfs can be set with 'rootflags=size=1024M'.
> >
> > Signed-off-by: Menglong Dong <[e-mail]>
> > ---
> >  init/do_mounts.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> >  init/do_mounts.h | 17 ++++++++++++++++-
> >  init/initramfs.c |  8 ++++++++
> >  usr/Kconfig      | 10 ++++++++++
> >  4 files changed, 78 insertions(+), 1 deletion(-)
> >
> > diff --git a/init/do_mounts.c b/init/do_mounts.c
> > index a78e44ee6adb..715bdaa89b81 100644
> > --- a/init/do_mounts.c
> > +++ b/init/do_mounts.c
> > @@ -618,6 +618,49 @@ void __init prepare_namespace(void)
> >  }
> >
> >  static bool is_tmpfs;
> > +#ifdef CONFIG_INITRAMFS_MOUNT
> > +
> > +/*
> > + * Give systems running from the initramfs and making use of pivot_root a
> > + * proper mount so it can be umounted during pivot_root.
> > + */
> > +int __init prepare_mount_rootfs(void)
> > +{
> > +     char *rootfs = "ramfs";
> > +
> > +     if (is_tmpfs)
> > +             rootfs = "tmpfs";
> > +
> > +     return do_mount_root(rootfs, rootfs,
> > +                          root_mountflags & ~MS_RDONLY,
> > +                          root_mount_data);
> > +}
> > +
> > +/*
> > + * Revert to previous mount by chdir to '/' and unmounting the second
> > + * mount.
> > + */
> > +void __init revert_mount_rootfs(void)
> > +{
> > +     init_chdir("/");
> > +     init_umount(".", MNT_DETACH);
> > +}
> > +
> > +/*
> > + * Change root to the new rootfs that mounted in prepare_mount_rootfs()
> > + * if cpio is unpacked successfully and 'ramdisk_execute_command' exist.
> > + */
> > +void __init finish_mount_rootfs(void)
> > +{
> > +     init_mount(".", "/", NULL, MS_MOVE, NULL);
> > +     if (likely(ramdisk_exec_exist()))
> > +             init_chroot(".");
> > +     else
> > +             revert_mount_rootfs();
> > +}
> > +
> > +#define rootfs_init_fs_context ramfs_init_fs_context
>
> Sorry, I think we're nearly there. What's the rationale for using ramfs
> when unconditionally when a separate mount for initramfs is requested?
> Meaning, why do we need this define at all?

I think it's necessary, as I explained in the third patch. When the rootfs
is a block device, ramfs is used in init_mount_tree() unconditionally,
which can be seen from the enable of is_tmpfs.

That makes sense, because rootfs will not become the root if a block
device is specified by 'root' in boot cmd, so it makes no sense to use
tmpfs, because ramfs is more simple.

Here, I make rootfs as ramfs for the same reason: the first mount is not
used as the root, so make it ramfs which is more simple.

Thanks!
Menglong Dong

>
> > +#else
> >  static int rootfs_init_fs_context(struct fs_context *fc)
> >  {
> >       if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
> > @@ -625,6 +668,7 @@ static int rootfs_init_fs_context(struct fs_context *fc)
> >
> >       return ramfs_init_fs_context(fc);
> >  }
> > +#endif
> >
> >  struct file_system_type rootfs_fs_type = {
> >       .name           = "rootfs",
> > diff --git a/init/do_mounts.h b/init/do_mounts.h
> > index 7a29ac3e427b..ae4ab306caa9 100644
> > --- a/init/do_mounts.h
> > +++ b/init/do_mounts.h
> > @@ -10,9 +10,24 @@
> >  #include <linux/root_dev.h>
> >  #include <linux/init_syscalls.h>
> >
> > +extern int root_mountflags;
> > +
> >  void  mount_block_root(char *name, int flags);
> >  void  mount_root(void);
> > -extern int root_mountflags;
> > +
> > +#ifdef CONFIG_INITRAMFS_MOUNT
> > +
> > +int  prepare_mount_rootfs(void);
> > +void finish_mount_rootfs(void);
> > +void revert_mount_rootfs(void);
> > +
> > +#else
> > +
> > +static inline int  prepare_mount_rootfs(void) { return 0; }
> > +static inline void finish_mount_rootfs(void) { }
> > +static inline void revert_mount_rootfs(void) { }
> > +
> > +#endif
> >
> >  static inline __init int create_dev(char *name, dev_t dev)
> >  {
> > diff --git a/init/initramfs.c b/init/initramfs.c
> > index af27abc59643..1833de3cf04e 100644
> > --- a/init/initramfs.c
> > +++ b/init/initramfs.c
> > @@ -16,6 +16,8 @@
> >  #include <linux/namei.h>
> >  #include <linux/init_syscalls.h>
> >
> > +#include "do_mounts.h"
> > +
> >  static ssize_t __init xwrite(struct file *file, const char *p, size_t count,
> >               loff_t *pos)
> >  {
> > @@ -682,13 +684,19 @@ static void __init do_populate_rootfs(void *unused, async_cookie_t cookie)
> >       else
> >               printk(KERN_INFO "Unpacking initramfs...\n");
> >
> > +     if (prepare_mount_rootfs())
> > +             panic("Failed to mount rootfs");
> > +
> >       err = unpack_to_rootfs((char *)initrd_start, initrd_end - initrd_start);
> >       if (err) {
> > +             revert_mount_rootfs();
> >  #ifdef CONFIG_BLK_DEV_RAM
> >               populate_initrd_image(err);
> >  #else
> >               printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
> >  #endif
> > +     } else {
> > +             finish_mount_rootfs();
> >       }
> >
> >  done:
> > diff --git a/usr/Kconfig b/usr/Kconfig
> > index 8bbcf699fe3b..4f6ac12eafe9 100644
> > --- a/usr/Kconfig
> > +++ b/usr/Kconfig
> > @@ -52,6 +52,16 @@ config INITRAMFS_ROOT_GID
> >
> >         If you are not sure, leave it set to "0".
> >
> > +config INITRAMFS_MOUNT
> > +     bool "Create second mount to make pivot_root() supported"
> > +     default y
> > +     help
> > +       Before unpacking cpio, create a second mount and make it become
> > +       the root filesystem. Therefore, initramfs will be supported by
> > +       pivot_root().
> > +
> > +       If container platforms is used with initramfs, say Y.
> > +
> >  config RD_GZIP
> >       bool "Support initial ramdisk/ramfs compressed using gzip"
> >       default y
> > --
> > 2.32.0.rc0
> >

Christian Brauner June 7, 2021, 10:31 a.m. UTC | #3

On Sat, Jun 05, 2021 at 10:47:07PM +0800, Menglong Dong wrote:
> Hello,
> 
> On Sat, Jun 5, 2021 at 7:50 PM Christian Brauner
> <[e-mail]> wrote:
> >
> > On Sat, Jun 05, 2021 at 11:44:47AM +0800, [e-mail] wrote:
> > > From: Menglong Dong <[e-mail]>
> > >
> > > 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 until all
> > > containers unmount the USB device.
> > >
> > > Another reason for container platforms such as Docker to use pivot_root
> > > is that upon initialization the net-namspace is mounted under
> > > /var/run/docker/netns/ on the host by dockerd. Without pivot_root
> > > Docker must either wait to create the network namespace prior to
> > > the creation of containers or simply deal with leaking this to each
> > > container.
> > >
> > > pivot_root is supported if the rootfs is a initrd or block device, but
> > > it's not supported if the rootfs uses an initramfs (tmpfs). This means
> > > container platforms today must resort to using block devices if
> > > they want to pivot_root from the rootfs. A workaround to use chroot()
> > > is not a clean viable option given every container will have a
> > > duplicate of every mount point on the host.
> > >
> > > In order to support using container platforms such as Docker on
> > > all the supported rootfs types we must extend Linux to support
> > > pivot_root on initramfs as well. This patch does the work to do
> > > just that.
> > >
> > > pivot_root will unmount the mount of the rootfs from its parent mount
> > > and mount the new root to it. However, when it comes to initramfs, it
> > > donesn't work, because the root filesystem has not parent mount, which
> > > makes initramfs not supported by pivot_root.
> > >
> > > In order to make pivot_root supported on initramfs, we create a second
> > > mount with type of rootfs before unpacking cpio, and change root to
> > > this mount after unpacking.
> > >
> > > While mounting the second rootfs, 'rootflags' is passed, and it means
> > > that we can set options for the mount of rootfs in boot cmd now.
> > > For example, the size of tmpfs can be set with 'rootflags=size=1024M'.
> > >
> > > Signed-off-by: Menglong Dong <[e-mail]>
> > > ---
> > >  init/do_mounts.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> > >  init/do_mounts.h | 17 ++++++++++++++++-
> > >  init/initramfs.c |  8 ++++++++
> > >  usr/Kconfig      | 10 ++++++++++
> > >  4 files changed, 78 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/init/do_mounts.c b/init/do_mounts.c
> > > index a78e44ee6adb..715bdaa89b81 100644
> > > --- a/init/do_mounts.c
> > > +++ b/init/do_mounts.c
> > > @@ -618,6 +618,49 @@ void __init prepare_namespace(void)
> > >  }
> > >
> > >  static bool is_tmpfs;
> > > +#ifdef CONFIG_INITRAMFS_MOUNT
> > > +
> > > +/*
> > > + * Give systems running from the initramfs and making use of pivot_root a
> > > + * proper mount so it can be umounted during pivot_root.
> > > + */
> > > +int __init prepare_mount_rootfs(void)
> > > +{
> > > +     char *rootfs = "ramfs";
> > > +
> > > +     if (is_tmpfs)
> > > +             rootfs = "tmpfs";
> > > +
> > > +     return do_mount_root(rootfs, rootfs,
> > > +                          root_mountflags & ~MS_RDONLY,
> > > +                          root_mount_data);
> > > +}
> > > +
> > > +/*
> > > + * Revert to previous mount by chdir to '/' and unmounting the second
> > > + * mount.
> > > + */
> > > +void __init revert_mount_rootfs(void)
> > > +{
> > > +     init_chdir("/");
> > > +     init_umount(".", MNT_DETACH);
> > > +}
> > > +
> > > +/*
> > > + * Change root to the new rootfs that mounted in prepare_mount_rootfs()
> > > + * if cpio is unpacked successfully and 'ramdisk_execute_command' exist.
> > > + */
> > > +void __init finish_mount_rootfs(void)
> > > +{
> > > +     init_mount(".", "/", NULL, MS_MOVE, NULL);
> > > +     if (likely(ramdisk_exec_exist()))
> > > +             init_chroot(".");
> > > +     else
> > > +             revert_mount_rootfs();
> > > +}
> > > +
> > > +#define rootfs_init_fs_context ramfs_init_fs_context
> >
> > Sorry, I think we're nearly there. What's the rationale for using ramfs
> > when unconditionally when a separate mount for initramfs is requested?
> > Meaning, why do we need this define at all?
> 
> I think it's necessary, as I explained in the third patch. When the rootfs
> is a block device, ramfs is used in init_mount_tree() unconditionally,
> which can be seen from the enable of is_tmpfs.
> 
> That makes sense, because rootfs will not become the root if a block
> device is specified by 'root' in boot cmd, so it makes no sense to use
> tmpfs, because ramfs is more simple.
> 
> Here, I make rootfs as ramfs for the same reason: the first mount is not
> used as the root, so make it ramfs which is more simple.

Ok. If you don't mind I'd like to pull and test this before moving
further. (Btw, I talked about this at Plumbers before btw.)
What did you use for testing this? Any way you can share it?

Menglong Dong June 7, 2021, 12:15 p.m. UTC | #4

On Mon, Jun 07, 2021 at 12:31:47PM +0200, Christian Brauner wrote:
> On Sat, Jun 05, 2021 at 10:47:07PM +0800, Menglong Dong wrote:
[...]
> > 
> > I think it's necessary, as I explained in the third patch. When the rootfs
> > is a block device, ramfs is used in init_mount_tree() unconditionally,
> > which can be seen from the enable of is_tmpfs.
> > 
> > That makes sense, because rootfs will not become the root if a block
> > device is specified by 'root' in boot cmd, so it makes no sense to use
> > tmpfs, because ramfs is more simple.
> > 
> > Here, I make rootfs as ramfs for the same reason: the first mount is not
> > used as the root, so make it ramfs which is more simple.
> 
> Ok. If you don't mind I'd like to pull and test this before moving
> further. (Btw, I talked about this at Plumbers before btw.)
> What did you use for testing this? Any way you can share it?

Ok, no problem definitely. I tested this function in 3 way mainly:

1. I debug the kernel with qemu and gdb, and trace the the whole
   process, to ensure that there is no abnormal situation.
2. I tested pivot_root() in initramfs and ensured that it can be
   used normally. What's more, I also tested docker and ensured
   container can run normally without 'DOCKER_RAMDISK=yes' set in
   initramfs.
3. I tried to enable and disable CONFIG_INITRAMFS_MOUNT, and
   ensured that the system can boot successfully from initramfs, initrd
   and sda.

What's more, our team is going to test it comprehensively, such as
ltp, etc.

Thanks!
Menglong Dong

Menglong Dong June 17, 2021, 3:57 a.m. UTC | #5

Hello,

On Mon, Jun 07, 2021 at 05:15:24AM -0700, [e-mail] wrote:
> On Mon, Jun 07, 2021 at 12:31:47PM +0200, Christian Brauner wrote:
> > On Sat, Jun 05, 2021 at 10:47:07PM +0800, Menglong Dong wrote:
> [...]
> > > 
> > > I think it's necessary, as I explained in the third patch. When the rootfs
> > > is a block device, ramfs is used in init_mount_tree() unconditionally,
> > > which can be seen from the enable of is_tmpfs.
> > > 
> > > That makes sense, because rootfs will not become the root if a block
> > > device is specified by 'root' in boot cmd, so it makes no sense to use
> > > tmpfs, because ramfs is more simple.
> > > 
> > > Here, I make rootfs as ramfs for the same reason: the first mount is not
> > > used as the root, so make it ramfs which is more simple.
> > 
> > Ok. If you don't mind I'd like to pull and test this before moving
> > further. (Btw, I talked about this at Plumbers before btw.)
> > What did you use for testing this? Any way you can share it?
> 

I notice that it have been ten days, and is it ok to move a little
further? (knock-knock :/)

Thanks!
Menglong Dong

> Ok, no problem definitely. I tested this function in 3 way mainly:
> 
> 1. I debug the kernel with qemu and gdb, and trace the the whole
>    process, to ensure that there is no abnormal situation.
> 2. I tested pivot_root() in initramfs and ensured that it can be
>    used normally. What's more, I also tested docker and ensured
>    container can run normally without 'DOCKER_RAMDISK=yes' set in
>    initramfs.
> 3. I tried to enable and disable CONFIG_INITRAMFS_MOUNT, and
>    ensured that the system can boot successfully from initramfs, initrd
>    and sda.
> 
> What's more, our team is going to test it comprehensively, such as
> ltp, etc.
> 
> Thanks!
> Menglong Dong                                                                                                                                                         
>

Christian Brauner June 17, 2021, 2:38 p.m. UTC | #6

On Wed, Jun 16, 2021 at 08:57:56PM -0700, Menglong Dong wrote:
> Hello,
> 
> On Mon, Jun 07, 2021 at 05:15:24AM -0700, [e-mail] wrote:
> > On Mon, Jun 07, 2021 at 12:31:47PM +0200, Christian Brauner wrote:
> > > On Sat, Jun 05, 2021 at 10:47:07PM +0800, Menglong Dong wrote:
> > [...]
> > > > 
> > > > I think it's necessary, as I explained in the third patch. When the rootfs
> > > > is a block device, ramfs is used in init_mount_tree() unconditionally,
> > > > which can be seen from the enable of is_tmpfs.
> > > > 
> > > > That makes sense, because rootfs will not become the root if a block
> > > > device is specified by 'root' in boot cmd, so it makes no sense to use
> > > > tmpfs, because ramfs is more simple.
> > > > 
> > > > Here, I make rootfs as ramfs for the same reason: the first mount is not
> > > > used as the root, so make it ramfs which is more simple.
> > > 
> > > Ok. If you don't mind I'd like to pull and test this before moving
> > > further. (Btw, I talked about this at Plumbers before btw.)
> > > What did you use for testing this? Any way you can share it?
> > 
> 
> I notice that it have been ten days, and is it ok to move a little
> further? (knock-knock :/)

Hey Menglong,

Since we're very close to the next kernel release it's unlikely that
anything will happen before the merge window has closed.
Otherwise I think we're close. I haven't had the time to test yet but if
nothing major comes up I'll pick it up and route it through my tree.
We need to be sure there's no regressions for anyone using this.

Thanks!
Christian

> 
> Thanks!
> Menglong Dong
> 
> > Ok, no problem definitely. I tested this function in 3 way mainly:
> > 
> > 1. I debug the kernel with qemu and gdb, and trace the the whole
> >    process, to ensure that there is no abnormal situation.
> > 2. I tested pivot_root() in initramfs and ensured that it can be
> >    used normally. What's more, I also tested docker and ensured
> >    container can run normally without 'DOCKER_RAMDISK=yes' set in
> >    initramfs.
> > 3. I tried to enable and disable CONFIG_INITRAMFS_MOUNT, and
> >    ensured that the system can boot successfully from initramfs, initrd
> >    and sda.
> > 
> > What's more, our team is going to test it comprehensively, such as
> > ltp, etc.
> > 
> > Thanks!
> > Menglong Dong                                                                                                                                                         
> >

Menglong Dong July 27, 2021, 12:24 p.m. UTC | #7

Hello Christian,

On Thu, Jun 17, 2021 at 10:38 PM Christian Brauner
<[e-mail]> wrote:
>
[...]
>
> Hey Menglong,
>
> Since we're very close to the next kernel release it's unlikely that
> anything will happen before the merge window has closed.
> Otherwise I think we're close. I haven't had the time to test yet but if
> nothing major comes up I'll pick it up and route it through my tree.
> We need to be sure there's no regressions for anyone using this.
>

Seems that it has been a month, and is it ok to move a little
further? (knock-knock :/)

Thanks!
Menglong Dong

Christian Brauner July 27, 2021, 12:37 p.m. UTC | #8

On Tue, Jul 27, 2021 at 08:24:03PM +0800, Menglong Dong wrote:
> Hello Christian,
> 
> On Thu, Jun 17, 2021 at 10:38 PM Christian Brauner
> <[e-mail]> wrote:
> >
> [...]
> >
> > Hey Menglong,
> >
> > Since we're very close to the next kernel release it's unlikely that
> > anything will happen before the merge window has closed.
> > Otherwise I think we're close. I haven't had the time to test yet but if
> > nothing major comes up I'll pick it up and route it through my tree.
> > We need to be sure there's no regressions for anyone using this.
> >
> 
> Seems that it has been a month, and is it ok to move a little
> further? (knock-knock :/)

Yep, sorry.
When I tested this early during the merge window it regressed booting a
regular system for me meaning if I compiled a kernel with this feature
enabled it complained about not being being able to open an initial
console and it dropped me right into initramfs instead of successfully
booting. I haven't looked into what this is caused or how to fix it for
lack of time.

Petr Mladek July 28, 2021, 8:07 a.m. UTC | #9

On Tue 2021-07-27 14:37:01, Christian Brauner wrote:
> On Tue, Jul 27, 2021 at 08:24:03PM +0800, Menglong Dong wrote:
> > Hello Christian,
> > 
> > On Thu, Jun 17, 2021 at 10:38 PM Christian Brauner
> > <[e-mail]> wrote:
> > >
> > [...]
> > >
> > > Hey Menglong,
> > >
> > > Since we're very close to the next kernel release it's unlikely that
> > > anything will happen before the merge window has closed.
> > > Otherwise I think we're close. I haven't had the time to test yet but if
> > > nothing major comes up I'll pick it up and route it through my tree.
> > > We need to be sure there's no regressions for anyone using this.
> > >
> > 
> > Seems that it has been a month, and is it ok to move a little
> > further? (knock-knock :/)
> 
> Yep, sorry.
> When I tested this early during the merge window it regressed booting a
> regular system for me meaning if I compiled a kernel with this feature
> enabled it complained about not being being able to open an initial
> console and it dropped me right into initramfs instead of successfully
> booting. I haven't looked into what this is caused or how to fix it for
> lack of time.

I guess that you have seen the following message printed by
console_on_rootfs():

      "Warning: unable to open an initial console."

This function is responsible for opening stdin, stdout, stderr
file to be used by the init process.

I am not sure how this is supposed to work with the pivot_root
and initramfs.


Some more details:

console_on_rootfs() tries to open /dev/console. It is created
by tty_init(). The open() callback calls:

  + tty_kopen()
    + tty_lookup_driver()
      + console_device()

, where console_device() iterates over all registered consoles
  and returns the first with tty binding.

There is ttynull_console that might be used as a fallback. But I
am not sure if this is what you want.

Best Regards,
Petr

Menglong Dong July 29, 2021, 1:25 p.m. UTC | #10

Hello,

On Wed, Jul 28, 2021 at 4:07 PM Petr Mladek <[e-mail]> wrote:
>
[...]
>
> I guess that you have seen the following message printed by
> console_on_rootfs():
>
>       "Warning: unable to open an initial console."
>
> This function is responsible for opening stdin, stdout, stderr
> file to be used by the init process.
>
> I am not sure how this is supposed to work with the pivot_root
> and initramfs.
>
>
> Some more details:
>
> console_on_rootfs() tries to open /dev/console. It is created
> by tty_init(). The open() callback calls:
>
>   + tty_kopen()
>     + tty_lookup_driver()
>       + console_device()
>
> , where console_device() iterates over all registered consoles
>   and returns the first with tty binding.
>
> There is ttynull_console that might be used as a fallback. But I
> am not sure if this is what you want.

I didn't figure out the relation between initramfs and initial console,
could you please tell me how this warning came up? I can't
reproduce it in qemu with this command:

qemu-system-x86_64 -nographic -m 2048M -smp cores=4,sockets=1 -s
-kernel ./bzImage -initrd ./rootfs.cpio -append "rdinit=/init
console=ttyS0"

Thanks!
Menglong Dong

>
> Best Regards,
> Petr

Menglong Dong Sept. 17, 2021, 1:58 a.m. UTC | #11

Hello,

On Tue, Jul 27, 2021 at 8:37 PM Christian Brauner
<[e-mail]> wrote:
[...]
>
> Yep, sorry.
> When I tested this early during the merge window it regressed booting a
> regular system for me meaning if I compiled a kernel with this feature
> enabled it complained about not being being able to open an initial
> console and it dropped me right into initramfs instead of successfully
> booting. I haven't looked into what this is caused or how to fix it for
> lack of time.

Our team has fully tested this feature, and no abnormalities have been
found yet.
What's more, this feature has been used in the product of our company. So if
there is any potential bug, as you mentioned above, I'd appreciate it if you can
spend some time on looking into it.

What's more, besides the problem that this feature solved, it has some more
benefits: saving memory. The amount of 'mnt_cache' is up to 50k when 180 docker
containers are created without this feature. However, only 15k 'mnt_cache' are
used with this feature enabled. Each 'mnt_cache' eats 320 bytes, so about 11M
memory is saved in this situation.

Please let me know if this feature is illogical or if there is any
better solution, thanks~

Best Wishes!
Menglong Dong

Patch

diff --git a/init/do_mounts.c b/init/do_mounts.c
index a78e44ee6adb..715bdaa89b81 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -618,6 +618,49 @@  void __init prepare_namespace(void)
 }
 
 static bool is_tmpfs;
+#ifdef CONFIG_INITRAMFS_MOUNT
+
+/*
+ * Give systems running from the initramfs and making use of pivot_root a
+ * proper mount so it can be umounted during pivot_root.
+ */
+int __init prepare_mount_rootfs(void)
+{
+	char *rootfs = "ramfs";
+
+	if (is_tmpfs)
+		rootfs = "tmpfs";
+
+	return do_mount_root(rootfs, rootfs,
+			     root_mountflags & ~MS_RDONLY,
+			     root_mount_data);
+}
+
+/*
+ * Revert to previous mount by chdir to '/' and unmounting the second
+ * mount.
+ */
+void __init revert_mount_rootfs(void)
+{
+	init_chdir("/");
+	init_umount(".", MNT_DETACH);
+}
+
+/*
+ * Change root to the new rootfs that mounted in prepare_mount_rootfs()
+ * if cpio is unpacked successfully and 'ramdisk_execute_command' exist.
+ */
+void __init finish_mount_rootfs(void)
+{
+	init_mount(".", "/", NULL, MS_MOVE, NULL);
+	if (likely(ramdisk_exec_exist()))
+		init_chroot(".");
+	else
+		revert_mount_rootfs();
+}
+
+#define rootfs_init_fs_context ramfs_init_fs_context
+#else
 static int rootfs_init_fs_context(struct fs_context *fc)
 {
 	if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
@@ -625,6 +668,7 @@  static int rootfs_init_fs_context(struct fs_context *fc)
 
 	return ramfs_init_fs_context(fc);
 }
+#endif
 
 struct file_system_type rootfs_fs_type = {
 	.name		= "rootfs",
diff --git a/init/do_mounts.h b/init/do_mounts.h
index 7a29ac3e427b..ae4ab306caa9 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -10,9 +10,24 @@ 
 #include <linux/root_dev.h>
 #include <linux/init_syscalls.h>
 
+extern int root_mountflags;
+
 void  mount_block_root(char *name, int flags);
 void  mount_root(void);
-extern int root_mountflags;
+
+#ifdef CONFIG_INITRAMFS_MOUNT
+
+int  prepare_mount_rootfs(void);
+void finish_mount_rootfs(void);
+void revert_mount_rootfs(void);
+
+#else
+
+static inline int  prepare_mount_rootfs(void) { return 0; }
+static inline void finish_mount_rootfs(void) { }
+static inline void revert_mount_rootfs(void) { }
+
+#endif
 
 static inline __init int create_dev(char *name, dev_t dev)
 {
diff --git a/init/initramfs.c b/init/initramfs.c
index af27abc59643..1833de3cf04e 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -16,6 +16,8 @@ 
 #include <linux/namei.h>
 #include <linux/init_syscalls.h>
 
+#include "do_mounts.h"
+
 static ssize_t __init xwrite(struct file *file, const char *p, size_t count,
 		loff_t *pos)
 {
@@ -682,13 +684,19 @@  static void __init do_populate_rootfs(void *unused, async_cookie_t cookie)
 	else
 		printk(KERN_INFO "Unpacking initramfs...\n");
 
+	if (prepare_mount_rootfs())
+		panic("Failed to mount rootfs");
+
 	err = unpack_to_rootfs((char *)initrd_start, initrd_end - initrd_start);
 	if (err) {
+		revert_mount_rootfs();
 #ifdef CONFIG_BLK_DEV_RAM
 		populate_initrd_image(err);
 #else
 		printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
 #endif
+	} else {
+		finish_mount_rootfs();
 	}
 
 done:
diff --git a/usr/Kconfig b/usr/Kconfig
index 8bbcf699fe3b..4f6ac12eafe9 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -52,6 +52,16 @@  config INITRAMFS_ROOT_GID
 
 	  If you are not sure, leave it set to "0".
 
+config INITRAMFS_MOUNT
+	bool "Create second mount to make pivot_root() supported"
+	default y
+	help
+	  Before unpacking cpio, create a second mount and make it become
+	  the root filesystem. Therefore, initramfs will be supported by
+	  pivot_root().
+
+	  If container platforms is used with initramfs, say Y.
+
 config RD_GZIP
 	bool "Support initial ramdisk/ramfs compressed using gzip"
 	default y