From: "H. Peter Anvin" <hpa@zytor.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Al Viro <viro@ftp.linux.org.uk>, Alain Knaff <alain@knaff.lu>
Subject: The policy on initramfs decompression failure
Date: Tue, 13 Jan 2009 14:38:49 -0800 [thread overview]
Message-ID: <496D17F9.8080605@zytor.com> (raw)
As part of the multi-compression-formats patch, the issue has come up as
to what is the preferred policy is on initramfs decompression failure,
due to either corruption or due to the use of a compression format which
the kernel does not support.
I had personally assumed the proper policy would be to panic, since it
is unlikely to mean the system can be booted. However, Ingo brought up
the case where the initramfs is auxilliary to being able to boot the
full system, for example the initramfs supplied is primarily a data
carrier, and either the builtin initramfs or the kernel itself is
sufficient to boot.
By this argument, we should change initramfs decoding failure to a
KERN_CRIT message, and in the (presumably most common) case that it does
not suffice to boot the system, we will get a panic in short order as
the system is unable to find init.
This argument seems to mostly hold water, but it does implement a policy
change over the current code. Furthermore, it does make me concerned
that a *partial* decoding failure (such as can be caused by a corrupt
image, or, say, a gzipped image concatenated to a bzip2 image, with the
kernel only supporting bzip2) could cause a booted-but-dysfunctional
system, which is in many configurations a worse failure mode than a panic.
Hence I would like to solicit opinions about what the policy should be.
-hpa
next reply other threads:[~2009-01-13 22:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 22:38 H. Peter Anvin [this message]
2009-01-13 23:17 ` The policy on initramfs decompression failure Alain Knaff
2009-01-14 5:40 ` Ingo Molnar
2009-01-14 7:02 ` Alain Knaff
2009-01-14 7:48 ` Ingo Molnar
2009-01-14 8:23 ` Alain Knaff
2009-01-14 10:37 ` Ingo Molnar
2009-01-14 17:42 ` H. Peter Anvin
2009-01-14 1:18 ` Theodore Tso
2009-01-14 6:51 ` Alain Knaff
[not found] <bU0fj-7Ap-43@gated-at.bofh.it>
2009-01-13 23:42 ` Bodo Eggert
2009-01-14 5:45 ` Ingo Molnar
2009-01-14 6:47 ` Alain Knaff
2009-01-14 7:45 ` Ingo Molnar
2009-01-14 15:19 ` Bodo Eggert
[not found] ` <bU0If-8vA-19@gated-at.bofh.it>
[not found] ` <bU6NE-1bi-3@gated-at.bofh.it>
[not found] ` <bU837-3lq-11@gated-at.bofh.it>
[not found] ` <bU8FR-4by-23@gated-at.bofh.it>
[not found] ` <bU9iw-5gV-1@gated-at.bofh.it>
[not found] ` <bUbkj-8un-5@gated-at.bofh.it>
2009-01-14 18:35 ` Bodo Eggert
[not found] ` <bUi2r-2kd-13@gated-at.bofh.it>
2009-01-18 12:55 ` Bodo Eggert
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=496D17F9.8080605@zytor.com \
--to=hpa@zytor.com \
--cc=alain@knaff.lu \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=viro@ftp.linux.org.uk \
/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