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 20:51:39 +1100 [thread overview]
Message-ID: <20250318205139.71fe0c02.ddiss@suse.de> (raw)
In-Reply-To: <BYAPR12MB320590A9238C334D68717C34D5DE2@BYAPR12MB3205.namprd12.prod.outlook.com>
On Tue, 18 Mar 2025 06:28:53 +0000, Stephen Eta Zhou wrote:
> > There's room for improvement WRT how out-of-memory failures are reported
>
> I am currently trying to find a good optimization solution for this. Since initramfs is decompressed in the early stage of the kernel, if the decompression fails, it will call panic to put the kernel into a panic state.
Not always. The *built-in* initramfs unpack_to_rootfs() error path
panics, but external initramfs unpack_to_rootfs() failure won't panic
immediately...
> There is a contradiction: at this time, the console and serial port have not been initialized yet, which will cause the error message to fail to be output, resulting in a suspended state, and no valid output can be seen.
Are your console/serial drivers loaded as external modules? That sounds
like a configuration problem.
next prev parent reply other threads:[~2025-03-18 9:51 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
2025-03-18 4:47 ` Stephen Eta Zhou
2025-03-18 6:28 ` Stephen Eta Zhou
2025-03-18 9:51 ` David Disseldorp [this message]
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=20250318205139.71fe0c02.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