[PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[H. Peter Anvin]

At Plumber's 2024, Lennart Poettering of the systemd project requested
the ability to overmount the rootfs with a separate tmpfs before
initramfs expansion, so the populated tmpfs can be unmounted.

This patchset takes this request and goes one step further: it allows
(mostly) arbitrary filesystems mounts during initramfs processing.

This is done by having the initramfs expansion code detect the special
filename "!!!MOUNT!!!" which is then parsed into a simplified
fstab-type mount specification and the directory in which the
!!!MOUNT!!! entry is used as the mount point.

This specific method was chosen for the following reasons:

1. This information is specific to the expectations of the initramfs;
   therefore using kernel command line options is not
   appropriate. This way the information is fully contained within the
   initramfs itself.
2. The sequence !!! is already special in cpio, due to the "TRAILER!!!"
   entries.
3. The filename "!!!MOUNT!!!" will typically be sorted first, which
   means using standard find+cpio tools to create the initramfs still
   work.
4. Similarly, standard cpio can still expand the initramfs.
5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which
   is easy to detect in the initramfs code which can then activate
   some fallback code.
6. It allows for multiple filesystems to be mounted, possibly of
   different types and in different locations, e.g. the initramfs can
   get started with /dev, /proc, and /sys already booted.

The patches are:

    1/3: fs/init: move creating the mount data_page into init_mount()
    2/3: initramfs: support mounting filesystems during initramfs expansion
    3/3: Documentation/initramfs: document mount points in initramfs

--- 
 .../driver-api/early-userspace/buffer-format.rst   | 60 +++++++++++++-
 fs/init.c                                          | 23 +++++-
 include/linux/init_syscalls.h                      |  3 +-
 init/do_mounts.c                                   | 17 +---
 init/initramfs.c                                   | 95 +++++++++++++++++++++-
 5 files changed, 175 insertions(+), 23 deletions(-)

[RFC PATCH 1/3] fs/init: move creating the mount data_page into init_mount()

[H. Peter Anvin]

path_mount() wants the mount data if not NULL to be a whole
page. Expanding a string onto an allocated page was done in
do_mount_root(); move it instead into init_mount() so other users of
init_mount() can leverage this same code.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
 fs/init.c                     | 23 ++++++++++++++++++++---
 include/linux/init_syscalls.h |  3 ++-
 init/do_mounts.c              | 17 ++---------------
 3 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/fs/init.c b/fs/init.c
index e0f5429c0a49..1253bcc73e26 100644
--- a/fs/init.c
+++ b/fs/init.c
@@ -14,16 +14,33 @@
 #include "internal.h"
 
 int __init init_mount(const char *dev_name, const char *dir_name,
-		const char *type_page, unsigned long flags, void *data_page)
+		      const char *type_page, unsigned long flags,
+		      const char *data_str)
 {
+	struct page *data_page = NULL;
+	char *data_buf = NULL;
 	struct path path;
 	int ret;
 
+	/* path_mount() wants a proper page for data */
+	if (data_str && data_str[0]) {
+		data_page = alloc_page(GFP_KERNEL);
+		if (!data_page)
+			return -ENOMEM;
+		data_buf = page_address(data_page);
+		strscpy_pad(data_buf, data_str, PAGE_SIZE);
+	}
+
 	ret = kern_path(dir_name, LOOKUP_FOLLOW, &path);
 	if (ret)
-		return ret;
-	ret = path_mount(dev_name, &path, type_page, flags, data_page);
+		goto out;
+
+	ret = path_mount(dev_name, &path, type_page, flags, data_buf);
 	path_put(&path);
+
+out:
+	if (data_page)
+		put_page(data_page);
 	return ret;
 }
 
diff --git a/include/linux/init_syscalls.h b/include/linux/init_syscalls.h
index 92045d18cbfc..804d3070ce73 100644
--- a/include/linux/init_syscalls.h
+++ b/include/linux/init_syscalls.h
@@ -1,7 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
 int __init init_mount(const char *dev_name, const char *dir_name,
-		const char *type_page, unsigned long flags, void *data_page);
+		      const char *type_page, unsigned long flags,
+		      const char *data_str);
 int __init init_umount(const char *name, int flags);
 int __init init_chdir(const char *filename);
 int __init init_chroot(const char *filename);
diff --git a/init/do_mounts.c b/init/do_mounts.c
index defbbf1d55f7..87cf110a48e6 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -147,23 +147,12 @@ static int __init split_fs_names(char *page, size_t size)
 }
 
 static int __init do_mount_root(const char *name, const char *fs,
-				 const int flags, const void *data)
+				 const int flags, const char *data)
 {
 	struct super_block *s;
-	struct page *p = NULL;
-	char *data_page = NULL;
 	int ret;
 
-	if (data) {
-		/* init_mount() requires a full page as fifth argument */
-		p = alloc_page(GFP_KERNEL);
-		if (!p)
-			return -ENOMEM;
-		data_page = page_address(p);
-		strscpy_pad(data_page, data, PAGE_SIZE);
-	}
-
-	ret = init_mount(name, "/root", fs, flags, data_page);
+	ret = init_mount(name, "/root", fs, flags, data);
 	if (ret)
 		goto out;
 
@@ -177,8 +166,6 @@ static int __init do_mount_root(const char *name, const char *fs,
 	       MAJOR(ROOT_DEV), MINOR(ROOT_DEV));
 
 out:
-	if (p)
-		put_page(p);
 	return ret;
 }
 
-- 
2.52.0

[RFC PATCH 2/3] initramfs: support mounting filesystems during initramfs expansion

[H. Peter Anvin]

Expanding the initramfs contents directly into the rootfs is not
always desirable. Allow the initramfs to contain instructions to mount
additional filesystems before continuing processing.

This is done by a magic filename !!!MOUNT!!! which, instead of being
expanded as a file, is processed as a simplified fstab(5) mount
specification (see following documentation patch.)

Some reasons this may be desirable:

1. The early init code may wish to expand into a separate tmpfs so it
   can be pivoted, remounted, or efficiently garbage collected on
   umount.
2. The early init code may which to pass some content, but not all, to
   the main userspace. This allows mounting a second tmpfs that can
   then be mounted underneath somewhere the main root without having
   to copy the contents.
3. The main userspace can retain the rootfs as the only root. In that
   case, the initramfs contents can be expanded into a tmpfs that is
   mounted at a different path. One use case for that might be
   /lib/modules.
4. It may be convenient for the early init code to have /dev, /proc
   and /sys pre-mounted.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
 init/initramfs.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 6ddbfb17fb8f..681ab59ab6cd 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -222,6 +222,7 @@ static __initdata enum state {
 	GotName,
 	CopyFile,
 	GotSymlink,
+	GotMountpoint,
 	Reset
 } state, next_state;
 
@@ -254,6 +255,9 @@ static void __init read_into(char *buf, unsigned size, enum state next)
 	}
 }
 
+#define SYMLINK_BUF_SIZE	(PATH_MAX + N_ALIGN(PATH_MAX) + 1)
+#define NAME_BUF_SIZE		N_ALIGN(PATH_MAX)
+
 static __initdata char *header_buf, *symlink_buf, *name_buf;
 
 static int __init do_start(void)
@@ -355,6 +359,37 @@ static int __init maybe_link(void)
 	return 0;
 }
 
+static int __init maybe_mountpoint(void)
+{
+	static const char mount_magic_name[] __initconst = "!!!MOUNT!!!";
+	const unsigned long mount_magic_len = sizeof(mount_magic_name)-1;
+	unsigned long len = name_len-1;
+	const char *name = collected;
+
+	if (!S_ISREG(mode))
+		return 0;
+	if (len < mount_magic_len)
+		return 0;
+	if (len > mount_magic_len && name[len-mount_magic_len] != '/')
+		return 0;
+	if (memcmp(name+len-mount_magic_len, mount_magic_name, mount_magic_len))
+		return 0;
+
+	/* Factor out the parent directory name and save it in name_buf */
+	len -= mount_magic_len;
+	if (!len)
+		name_buf[len++] = '.';
+	else
+		memmove(name_buf, name, len);
+	name_buf[len] = '\0';
+
+	if (body_len >= SYMLINK_BUF_SIZE)
+		return 1;	/* Option file too large */
+
+	read_into(symlink_buf, body_len, GotMountpoint);
+	return 1;
+}
+
 static __initdata struct file *wfile;
 static __initdata loff_t wfile_pos;
 
@@ -375,6 +410,10 @@ static int __init do_name(void)
 		free_hash();
 		return 0;
 	}
+
+	if (maybe_mountpoint())
+		return 0;
+
 	clean_path(collected, mode);
 	if (S_ISREG(mode)) {
 		int ml = maybe_link();
@@ -392,6 +431,7 @@ static int __init do_name(void)
 			vfs_fchmod(wfile, mode);
 			if (body_len)
 				vfs_truncate(&wfile->f_path, body_len);
+
 			state = CopyFile;
 		}
 	} else if (S_ISDIR(mode)) {
@@ -451,6 +491,56 @@ static int __init do_symlink(void)
 	return 0;
 }
 
+static int __init do_mountpoint(void)
+{
+	int ret;
+	char *p, *ep;
+	const char *opts[3];
+	const char *opstart;
+	unsigned long n;
+
+	state = SkipIt;
+	next_state = Reset;
+
+	memset(opts, 0, sizeof(opts));
+
+	/* Default filesystem type */
+	opts[0] = IS_ENABLED(CONFIG_TMPFS) ? "tmpfs" : "ramfs";
+
+	p = collected;
+	ep = p + body_len;
+	n = 0;
+	opstart = NULL;
+	while (p < ep && n < 3) {
+		char c = *p;
+		if (c <= ' ') {
+			if (opstart) {
+				*p = '\0';
+				opts[n++] = opstart;
+				opstart = NULL;
+			}
+		} else {
+			if (!opstart)
+				opstart = p;
+		}
+		p++;
+	}
+
+	if (!opts[1])
+		opts[1] = opts[0];
+
+	ret = init_mount(opts[0], name_buf, opts[1], 0, opts[2]);
+	if (!ret) {
+		init_chown(name_buf, uid, gid, 0);
+		init_chmod(name_buf, mode); /* S_IFMT is ignored by chmod() */
+		dir_add(name_buf, name_len, mtime);
+	} else {
+		pr_err("initramfs mount %s %s %s failed, error %d\n",
+		       opts[0], name_buf, opts[1], ret);
+	}
+	return 0;
+}
+
 static __initdata int (*actions[])(void) = {
 	[Start]		= do_start,
 	[Collect]	= do_collect,
@@ -459,6 +549,7 @@ static __initdata int (*actions[])(void) = {
 	[GotName]	= do_name,
 	[CopyFile]	= do_copy,
 	[GotSymlink]	= do_symlink,
+	[GotMountpoint] = do_mountpoint,
 	[Reset]		= do_reset,
 };
 
@@ -515,8 +606,8 @@ char * __init unpack_to_rootfs(char *buf, unsigned long len)
 	const char *compress_name;
 	struct {
 		char header[CPIO_HDRLEN];
-		char symlink[PATH_MAX + N_ALIGN(PATH_MAX) + 1];
-		char name[N_ALIGN(PATH_MAX)];
+		char symlink[SYMLINK_BUF_SIZE];
+		char name[NAME_BUF_SIZE];
 	} *bufs = kmalloc(sizeof(*bufs), GFP_KERNEL);
 
 	if (!bufs)

[RFC PATCH 3/3] Documentation/initramfs: document mount points in initramfs

[H. Peter Anvin]

Document how to create mount points in initramfs, using magic
"!!!MOUNT!!!" file entries, the format the kernel expects for these
files, and their exact semantics.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
 .../early-userspace/buffer-format.rst         | 60 ++++++++++++++++++-
 1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/early-userspace/buffer-format.rst b/Documentation/driver-api/early-userspace/buffer-format.rst
index 4597a91100b7..40f86b9eec75 100644
--- a/Documentation/driver-api/early-userspace/buffer-format.rst
+++ b/Documentation/driver-api/early-userspace/buffer-format.rst
@@ -8,8 +8,8 @@ With kernel 2.5.x, the old "initial ramdisk" protocol was complemented
 with an "initial ramfs" protocol.  The initramfs content is passed
 using the same memory buffer protocol used by initrd, but the content
 is different.  The initramfs buffer contains an archive which is
-expanded into a ramfs filesystem; this document details the initramfs
-buffer format.
+expanded into a tmpfs or ramfs filesystem; this document details the
+initramfs buffer format.
 
 The initramfs buffer format is based around the "newc" or "crc" CPIO
 formats, and can be created with the cpio(1) utility.  The cpio
@@ -17,6 +17,9 @@ archive can be compressed using gzip(1), or any other algorithm provided
 via CONFIG_DECOMPRESS_*.  One valid version of an initramfs buffer is
 thus a single .cpio.gz file.
 
+In kernel version XXXX the feature to mount additional filesystems
+during initramfs expansion was introduced, see below.
+
 The full format of the initramfs buffer is defined by the following
 grammar, where::
 
@@ -130,3 +133,56 @@ a) Separate the different file data sources with a "TRAILER!!!"
    end-of-archive marker, or
 
 b) Make sure c_nlink == 1 for all nondirectory entries.
+
+
+Mounting additional filesystems
+===============================
+
+If a regular file with the special name "!!!MOUNT!!!" is encountered
+during initramfs processing, the file contents is parsed as a mount
+specification in format similar to fstab(5). It should contain of a
+single line in one of the following formats::
+
+	fs_spec fs_vfstype fs_mntops
+	fs_spec fs_vfstype
+	fs_vfstype
+
+
+Comment or blank lines are NOT allowed, and the terminating newline is
+required.
+
+The specified filesystem is then mounted onto the directory in which
+the !!!MOUNT!!! file is located, for example, if the file is named::
+
+	dev/!!!MOUNT!!!
+
+
+then the filesystem will be mounted onto the /dev directory, which
+must already exist.
+
+The mount is performed immediately, before processing any further
+initramfs entries.
+
+The c_mode, c_uid, c_gid, and c_mtime (with CONFIG_INITRAMFS_PRESERVE_MTIME)
+values for the file are applied to the root directory of the newly
+mounted filesystem, if that filesystem is writable and allows those
+operations. Therefore, the !!!MOUNT!!!  file should typically have the
+x permission bit set, as a directory would.
+
+fs_spec or fs_mntops values that require user space support, such as
+LABEL= or UUID=, are not supported. To mount a filesystem that
+requires a block device, the appropriate /dev entry need to have
+been created, or devtmpfs have been mounted, earlier in the initramfs
+image.
+
+A !!!MOUNT!!! entry in the cpio archive root, or multiple !!!MOUNT!!!
+entries for the same path, will cause overmounts. This allows the
+initramfs to be expanded into a tmpfs that is separate from the
+rootfs, and which therefore, unlike the rootfs, can be unmounted.
+
+The special name !!!MOUNT!!! was chosen because the sequence !!!
+already has special meaning in cpio (the TRAILER!!! entry) and because
+! is the lowest-numbered non-blank character in ASCII. Therefore
+creating a sorted cpio archive will naturally end up with the
+!!!MOUNT!!! entry immediately after the directory itself and before
+its contents.
-- 
2.52.0

Re: [PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[Askar Safin]

"H. Peter Anvin" <hpa@zytor.com>:
> At Plumber's 2024, Lennart Poettering of the systemd project requested
> the ability to overmount the rootfs with a separate tmpfs before
> initramfs expansion, so the populated tmpfs can be unmounted.

This is already solved by [1] and [2]. They are in next.

[1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/
[2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/

-- 
Askar Safin

Re: [PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[H. Peter Anvin]

On January 24, 2026 9:41:50 AM PST, Askar Safin <safinaskar@gmail.com> wrote:
>"H. Peter Anvin" <hpa@zytor.com>:
>> At Plumber's 2024, Lennart Poettering of the systemd project requested
>> the ability to overmount the rootfs with a separate tmpfs before
>> initramfs expansion, so the populated tmpfs can be unmounted.
>
>This is already solved by [1] and [2]. They are in next.
>
>[1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/
>[2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/
>

Well, all right then :)

Re: [PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[H. Peter Anvin]

On 2026-01-24 09:41, Askar Safin wrote:
> "H. Peter Anvin" <hpa@zytor.com>:
>> At Plumber's 2024, Lennart Poettering of the systemd project requested
>> the ability to overmount the rootfs with a separate tmpfs before
>> initramfs expansion, so the populated tmpfs can be unmounted.
> 
> This is already solved by [1] and [2]. They are in next.
> 
> [1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/
> [2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/
> 

Just to make it clear: unless someone feels there is value in this feature
regardless of the above, there is no need for this patchset.

	-hpa

RE: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[Windl, Ulrich]

Hi!

I wonder: wouldn't it be nicer to use a subdirectory like ".systemd-magic" to place such magic files there that are interpreted by systemd? Then "!!!MOUNT!!!" would become a simple "mount" or maybe "fstab" or "mountttab", ...

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: systemd-devel <systemd-devel-bounces@lists.freedesktop.org> On
> Behalf Of H. Peter Anvin
> Sent: Saturday, January 24, 2026 1:40 AM
> To: Alexander Viro <viro@zeniv.linux.org.uk>; Christian Brauner
> <brauner@kernel.org>; Jan Kara <jack@suse.cz>; Jonathan Corbet
> <corbet@lwn.net>; H. Peter Anvin <hpa@zytor.com>
> Cc: linux-fsdevel@vger.kernel.org; linux-doc@vger.kernel.org; linux-
> kernel@vger.kernel.org; Lennart Poettering <lennart@poettering.net>;
> systemd-devel@lists.freedesktop.org
> Subject: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount
> filesystems during initramfs expansion
> 
> 
> At Plumber's 2024, Lennart Poettering of the systemd project requested
> the ability to overmount the rootfs with a separate tmpfs before
> initramfs expansion, so the populated tmpfs can be unmounted.
> 
> This patchset takes this request and goes one step further: it allows
> (mostly) arbitrary filesystems mounts during initramfs processing.
> 
> This is done by having the initramfs expansion code detect the special
> filename "!!!MOUNT!!!" which is then parsed into a simplified
> fstab-type mount specification and the directory in which the
> !!!MOUNT!!! entry is used as the mount point.
> 
> This specific method was chosen for the following reasons:
> 
> 1. This information is specific to the expectations of the initramfs;
>    therefore using kernel command line options is not
>    appropriate. This way the information is fully contained within the
>    initramfs itself.
> 2. The sequence !!! is already special in cpio, due to the "TRAILER!!!"
>    entries.
> 3. The filename "!!!MOUNT!!!" will typically be sorted first, which
>    means using standard find+cpio tools to create the initramfs still
>    work.
> 4. Similarly, standard cpio can still expand the initramfs.
> 5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which
>    is easy to detect in the initramfs code which can then activate
>    some fallback code.
> 6. It allows for multiple filesystems to be mounted, possibly of
>    different types and in different locations, e.g. the initramfs can
>    get started with /dev, /proc, and /sys already booted.
> 
> The patches are:
> 
>     1/3: fs/init: move creating the mount data_page into init_mount()
>     2/3: initramfs: support mounting filesystems during initramfs expansion
>     3/3: Documentation/initramfs: document mount points in initramfs
> 
> ---
>  .../driver-api/early-userspace/buffer-format.rst   | 60 +++++++++++++-
>  fs/init.c                                          | 23 +++++-
>  include/linux/init_syscalls.h                      |  3 +-
>  init/do_mounts.c                                   | 17 +---
>  init/initramfs.c                                   | 95 +++++++++++++++++++++-
>  5 files changed, 175 insertions(+), 23 deletions(-)

RE: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount filesystems during initramfs expansion

[H. Peter Anvin]

On February 1, 2026 11:38:23 PM PST, "Windl, Ulrich" <u.windl@ukr.de> wrote:
>Hi!
>
>I wonder: wouldn't it be nicer to use a subdirectory like ".systemd-magic" to place such magic files there that are interpreted by systemd? Then "!!!MOUNT!!!" would become a simple "mount" or maybe "fstab" or "mountttab", ...
>
>Kind regards,
>Ulrich Windl
>
>> -----Original Message-----
>> From: systemd-devel <systemd-devel-bounces@lists.freedesktop.org> On
>> Behalf Of H. Peter Anvin
>> Sent: Saturday, January 24, 2026 1:40 AM
>> To: Alexander Viro <viro@zeniv.linux.org.uk>; Christian Brauner
>> <brauner@kernel.org>; Jan Kara <jack@suse.cz>; Jonathan Corbet
>> <corbet@lwn.net>; H. Peter Anvin <hpa@zytor.com>
>> Cc: linux-fsdevel@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>> kernel@vger.kernel.org; Lennart Poettering <lennart@poettering.net>;
>> systemd-devel@lists.freedesktop.org
>> Subject: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount
>> filesystems during initramfs expansion
>> 
>> 
>> At Plumber's 2024, Lennart Poettering of the systemd project requested
>> the ability to overmount the rootfs with a separate tmpfs before
>> initramfs expansion, so the populated tmpfs can be unmounted.
>> 
>> This patchset takes this request and goes one step further: it allows
>> (mostly) arbitrary filesystems mounts during initramfs processing.
>> 
>> This is done by having the initramfs expansion code detect the special
>> filename "!!!MOUNT!!!" which is then parsed into a simplified
>> fstab-type mount specification and the directory in which the
>> !!!MOUNT!!! entry is used as the mount point.
>> 
>> This specific method was chosen for the following reasons:
>> 
>> 1. This information is specific to the expectations of the initramfs;
>>    therefore using kernel command line options is not
>>    appropriate. This way the information is fully contained within the
>>    initramfs itself.
>> 2. The sequence !!! is already special in cpio, due to the "TRAILER!!!"
>>    entries.
>> 3. The filename "!!!MOUNT!!!" will typically be sorted first, which
>>    means using standard find+cpio tools to create the initramfs still
>>    work.
>> 4. Similarly, standard cpio can still expand the initramfs.
>> 5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which
>>    is easy to detect in the initramfs code which can then activate
>>    some fallback code.
>> 6. It allows for multiple filesystems to be mounted, possibly of
>>    different types and in different locations, e.g. the initramfs can
>>    get started with /dev, /proc, and /sys already booted.
>> 
>> The patches are:
>> 
>>     1/3: fs/init: move creating the mount data_page into init_mount()
>>     2/3: initramfs: support mounting filesystems during initramfs expansion
>>     3/3: Documentation/initramfs: document mount points in initramfs
>> 
>> ---
>>  .../driver-api/early-userspace/buffer-format.rst   | 60 +++++++++++++-
>>  fs/init.c                                          | 23 +++++-
>>  include/linux/init_syscalls.h                      |  3 +-
>>  init/do_mounts.c                                   | 17 +---
>>  init/initramfs.c                                   | 95 +++++++++++++++++++++-
>>  5 files changed, 175 insertions(+), 23 deletions(-)
>

The point is that this is done during initramfs deencapsulation.

Either way, it doesn't seem like there is interest.