Message-ID:
 <BYAPR12MB320504EE908AABFD1600AB87D5DE2@BYAPR12MB3205.namprd12.prod.outlook.com>
Date: Tue, 18 Mar 2025 04:47:06 +0000
From: Stephen Eta Zhou <stephen.eta.zhou@...look.com>
To: David Disseldorp <ddiss@...e.de>
CC: "jsperbeck@...gle.com" <jsperbeck@...gle.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>, "lukas@...ner.de" <lukas@...ner.de>,
	"wufan@...ux.microsoft.com" <wufan@...ux.microsoft.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC PATCH] initramfs: Add size validation to prevent tmpfs
 exhaustion


> I0t's still not clear to me why early-user-space can't determine this
> before attempting to mount, etc. It's in a better position to know the
> resource requirements of what it's going to run.

Before init runs, initramfs is unpacked to tmpfs, and if tmpfs runs out of resources, the system may already be in an unrecoverable state (crash or panic), which can cause problems: the system may be in an unrecoverable state before init has a chance to check.
Unrecoverable state can come from drivers or subsystems that cannot create files in tmpfs. For example, if the rootfs is created on a system with very limited RAM (e.g., an embedded device with 64MB RAM), unpacking a large initramfs may leave so little space that even init cannot allocate memory.
The kernel error log may show OOM errors, but the underlying problem is that the initramfs is too large and there is not enough space left to support subsequent programs.

So I think the kernel should provide protection during decompression, so that if tmpfs is insufficient, the kernel can handle the error gracefully and accurately, without running at the risk of panic or crash. At least when such a situation occurs, developers will know where the problem is at a glance, and spend too much energy to gradually troubleshoot the problem, and it can also strengthen the kernel's ability to handle problems early.

Sometimes when we troubleshoot errors, we always check step by step, and finally find that the problem may have occurred in the first link or some parameter configuration at the beginning of startup. In this case, why can't we expose the problem as soon as possible?


> There's room for improvement WRT how out-of-memory failures are reported

> and handled during decompression and I/O. However, adding an extra pass

> and some arbitrary free-space logic doesn't improve the situation IMO.

My intention is that pre-checking free space before unpacking ensures that failures are predictable and recoverable. This check can be a simple size comparison between the initramfs archive and the free tmpfs space, which has minimal overhead compared to a full unpack and subsequent failure.
Proactive checking prevents unnecessary I/O operations and reduces the complexity of debugging at boot time.
This is done to provide early assurance to the kernel.

Thanks,
Stephen
________________________________________
From: David Disseldorp
Sent: Tuesday, March 18, 2025 09:14
To: Stephen Eta Zhou
Cc: jsperbeck@...gle.com; akpm@...ux-foundation.org; gregkh@...uxfoundation.org; lukas@...ner.de; wufan@...ux.microsoft.com; linux-kernel@...r.kernel.org; linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH] initramfs: Add size validation to prevent tmpfs exhaustion


On Mon, 17 Mar 2025 09:41:35 +0000, Stephen Eta Zhou wrote:

...

> Before the init process runs, initramfs needs to be decompressed to tmpfs and become the root file system (rootfs). If there is insufficient tmpfs space after decompression, init may not be able to run at all, causing the system to crash or panic.

>

> Letting the init process decide whether it is sufficient means that the initramfs must be decompressed first, which may have filled up tmpfs, making the entire system unusable, rather than a controllable error handling process.

>

> This problem is more obvious in extreme cases, for example:

>

> 1. After initramfs is decompressed, there is only a small amount of available space in tmpfs, causing early-user-space tasks such as mount and udevadm to fail, affecting device initialization.



It's still not clear to me why early-user-space can't determine this

before attempting to mount, etc. It's in a better position to know the

resource requirements of what it's going to run.



> 2. On embedded devices, tmpfs is usually configured small, and insufficient space is found after decompression, which directly leads to boot failure.

>

> The reason why the check is performed before decompression is to expose the problem in advance to avoid the passive failure mode of insufficient space after decompression.

> Calculating the theoretically required tmpfs resources and making judgments in advance can reduce unnecessary I/O operations and provide clearer error reports to help users adjust the initramfs size or tmpfs configuration.

> My idea is to expose problems as early as possible. If problems occur during operation, it may be more troublesome to troubleshoot or bring unnecessary risks.



There's room for improvement WRT how out-of-memory failures are reported

and handled during decompression and I/O. However, adding an extra pass

and some arbitrary free-space logic doesn't improve the situation IMO.



Cheers, David

Powered by blists - more mailing lists