public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Stephen Eta Zhou <stephen.eta.zhou@outlook.com>
Cc: "jsperbeck@google.com" <jsperbeck@google.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"lukas@wunner.de" <lukas@wunner.de>,
	"wufan@linux.microsoft.com" <wufan@linux.microsoft.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH] initramfs: Add size validation to prevent tmpfs exhaustion
Date: Tue, 18 Mar 2025 12:14:24 +1100	[thread overview]
Message-ID: <20250318121424.614148e1.ddiss@suse.de> (raw)
In-Reply-To: <BYAPR12MB3205A7903D8EF06EFF8F575AD5DF2@BYAPR12MB3205.namprd12.prod.outlook.com>

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

  reply	other threads:[~2025-03-18  1:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14  5:04 [RFC PATCH] initramfs: Add size validation to prevent tmpfs exhaustion Stephen Eta Zhou
2025-03-17  7:21 ` David Disseldorp
2025-03-17  9:41   ` Stephen Eta Zhou
2025-03-18  1:14     ` David Disseldorp [this message]
2025-03-18  4:47       ` Stephen Eta Zhou
2025-03-18  6:28       ` Stephen Eta Zhou
2025-03-18  9:51         ` David Disseldorp
2025-03-18 12:36           ` Stephen Eta Zhou
2025-03-18 11:55   ` Krzysztof Kozlowski
2025-03-18 12:46     ` Stephen Eta Zhou
2025-03-18 19:01       ` Krzysztof Kozlowski
  -- strict thread matches above, loose matches on Subject: below --
2025-03-19  7:59 Stephen Eta Zhou

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=20250318121424.614148e1.ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jsperbeck@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=stephen.eta.zhou@outlook.com \
    --cc=wufan@linux.microsoft.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