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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.