From: Lichen Liu <lichliu@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, rob@landley.net,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
weilongchen@huawei.com
Subject: Re: [PATCH] fs: Add 'rootfsflags' to set rootfs mount options
Date: Fri, 8 Aug 2025 11:36:42 +0800 [thread overview]
Message-ID: <CAPmSd0OQfSHBqDSpFLNAddk-f_aDcjzKt_VBzLWjNqvMAXgzkQ@mail.gmail.com> (raw)
In-Reply-To: <CALu+AoTGY0wKubVgR_EF5BZmYvh180fjP1AsLvp8cJ447WFGaA@mail.gmail.com>
On Fri, Aug 8, 2025 at 10:46 AM Dave Young <dyoung@redhat.com> wrote:
>
> On Fri, 8 Aug 2025 at 10:30, Dave Young <dyoung@redhat.com> wrote:
> >
> > Hi Lichen,
> >
> > On Fri, 8 Aug 2025 at 09:55, Lichen Liu <lichliu@redhat.com> wrote:
> > >
> > > When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs.
> > > By default, a tmpfs mount is limited to using 50% of the available RAM
> > > for its content. This can be problematic in memory-constrained
> > > environments, particularly during a kdump capture.
> > >
> > > In a kdump scenario, the capture kernel boots with a limited amount of
> > > memory specified by the 'crashkernel' parameter. If the initramfs is
> > > large, it may fail to unpack into the tmpfs rootfs due to insufficient
> > > space. This is because to get X MB of usable space in tmpfs, 2*X MB of
> > > memory must be available for the mount. This leads to an OOM failure
> > > during the early boot process, preventing a successful crash dump.
> > >
> > > This patch introduces a new kernel command-line parameter, rootfsflags,
> > > which allows passing specific mount options directly to the rootfs when
> > > it is first mounted. This gives users control over the rootfs behavior.
> > >
> > > For example, a user can now specify rootfsflags=size=75% to allow the
> > > tmpfs to use up to 75% of the available memory. This can significantly
> > > reduce the memory pressure for kdump.
> > >
> > > Consider a practical example:
> > >
> > > To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With
> > > the default 50% limit, this requires a memory pool of 96MB to be
> > > available for the tmpfs mount. The total memory requirement is therefore
> > > approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked
> > > kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB.
> > >
> > > By using rootfsflags=size=75%, the memory pool required for the 48MB
> > > tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory
> > > requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a
> > > smaller crashkernel size, such as 192MB.
> > >
> > > An alternative approach of reusing the existing rootflags parameter was
> > > considered. However, a new, dedicated rootfsflags parameter was chosen
> > > to avoid altering the current behavior of rootflags (which applies to
> > > the final root filesystem) and to prevent any potential regressions.
> > >
> > > This approach is inspired by prior discussions and patches on the topic.
> > > Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128
> > > Ref: https://landley.net/notes-2015.html#01-01-2015
> > > Ref: https://lkml.org/lkml/2021/6/29/783
> > > Ref: https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs
> > >
> > > Signed-off-by: Lichen Liu <lichliu@redhat.com>
> > > ---
> > > fs/namespace.c | 11 ++++++++++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/fs/namespace.c b/fs/namespace.c
> > > index ddfd4457d338..a450db31613e 100644
> > > --- a/fs/namespace.c
> > > +++ b/fs/namespace.c
> > > @@ -65,6 +65,15 @@ static int __init set_mphash_entries(char *str)
> > > }
> > > __setup("mphash_entries=", set_mphash_entries);
> > >
> > > +static char * __initdata rootfs_flags;
> > > +static int __init rootfs_flags_setup(char *str)
> > > +{
> > > + rootfs_flags = str;
> >
> > I do see there are a few similar usages in init/do_mounts.c, probably
> > it is old stuff and it just works. But I think making rootfs_flags as
> > an array and copying str into it is the right way.
Hi Dave, thanks for your comments!
I will check how to make it better.
>
> Another question, may need fs people to clarify. If the mount is
> tmpfs and it is also rootfs, could it use 100% of the memory by
> default, and then no need for an extra param? I feel that there is
> no point to reserve memory if it is a fully memory based file system.
>
I think rootfstype=ramfs will use 100% of the memory.
For kdump only, there might not be much difference between using ramfs
and tmpfs size=100%. But I think it might provide more flexibility
since rootfstype= and rootflags= can be used with root=.
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
> >
> > > + return 1;
> > > +}
> > > +
> > > +__setup("rootfsflags=", rootfs_flags_setup);
> > > +
> > > static u64 event;
> > > static DEFINE_XARRAY_FLAGS(mnt_id_xa, XA_FLAGS_ALLOC);
> > > static DEFINE_IDA(mnt_group_ida);
> > > @@ -6086,7 +6095,7 @@ static void __init init_mount_tree(void)
> > > struct mnt_namespace *ns;
> > > struct path root;
> > >
> > > - mnt = vfs_kern_mount(&rootfs_fs_type, 0, "rootfs", NULL);
> > > + mnt = vfs_kern_mount(&rootfs_fs_type, 0, "rootfs", rootfs_flags);
> > > if (IS_ERR(mnt))
> > > panic("Can't create rootfs");
> > >
> > > --
> > > 2.50.1
> > >
> > >
> > Thanks
> > Dave
>
next prev parent reply other threads:[~2025-08-08 3:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 1:51 [PATCH] fs: Add 'rootfsflags' to set rootfs mount options Lichen Liu
2025-08-08 2:30 ` Dave Young
2025-08-08 2:47 ` Dave Young
2025-08-08 3:36 ` Lichen Liu [this message]
2025-08-08 17:59 ` Rob Landley
2025-08-11 1:57 ` Lichen Liu
2025-08-08 14:38 ` Rob Landley
2025-08-09 15:02 ` Rob Landley
2025-08-14 8:13 ` Askar Safin
2025-08-14 10:25 ` Lichen Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPmSd0OQfSHBqDSpFLNAddk-f_aDcjzKt_VBzLWjNqvMAXgzkQ@mail.gmail.com \
--to=lichliu@redhat.com \
--cc=brauner@kernel.org \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@landley.net \
--cc=viro@zeniv.linux.org.uk \
--cc=weilongchen@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).