From: ebiederm@xmission.com (Eric W. Biederman)
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Americo Wang <xiyou.wangcong@gmail.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Jarod Wilson <jwilson@redhat.com>
Subject: Re: [Patch] kexec: remove KMSG_DUMP_KEXEC (was Re: Query about kdump_msg hook into crash_kexec())
Date: Wed, 01 Jun 2011 20:26:20 -0700 [thread overview]
Message-ID: <m1ei3cq5gj.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <5C4C569E8A4B9B42A84A977CF070A35B2C17324BB9@USINDEVS01.corp.hds.com> (Seiji Aguchi's message of "Tue, 31 May 2011 18:24:14 -0400")
Seiji Aguchi <seiji.aguchi@hds.com> writes:
> Hi,
>
>>What are you using kmsg_dump() for? Using mtdoops, ramoops or something
>>else? Is it working reliably for you?
>
> I plan to use kmsg_dump() for set_variable service of UEFI.
> I proposed a prototype patch this month and will improve it.
> (kmsg_dump is used inside pstore.)
>
> https://lkml.org/lkml/2011/5/10/340
Shudder. Firmware calls in the crash path.
If that is the use, we need to remove the kmsg_dump(KMSG_DUMP_KEXEC)
hook from crash_kexec yesterday. It is leading to some really ludicrous
suggestions that are on the way from making kexec on panic unreliable
and useless.
There will always be EFI implementations where that will not work and
there will be no way we can fix those.
There is a long history of people trying to do things in a crashing
kernel, things that simply do not work when the system is in a bad
state. kmsg_dump() when I reviewed the code had significant
implementation problems for being called from interrupt handlers
and the like.
To introduce a different solution for capturing information when a
kernel crashes we need to see numbers that in a large number of
situations that the mechanism you are proposing is more reliable and/or
more maintainable than the current kexec on panic implementation.
The best work I know of on the reliability of the current situation
is "Evaluating Linux Kernel Crash Dumping Mechanisms", by Fernando Luis Vazquez Cao.
http://www.linuxsymposium.org/archives/OLS/Reprints-2006/cao-reprint.pdf
Now it does happen to be a fact that our efi support in linux is
so buggy kexec does not work let alone kexec on panic (if the target
kernel has any efi support). But our efi support being buggy is not
a reason to add more ways to fail when we have a kernel with efi
support. It is an argument to remove our excessive use of EFI
calls.
So let's just remove the ridiculous kmsg_dump(KMSG_DUMP_KEXEC) hook from
crash_kexec and remove any temptation for abuses like wanting to use
kmsg_dump() on anything but a deeply embedded system where there simply
is not enough memory for 2 kernels.
Eric
next prev parent reply other threads:[~2011-06-02 3:26 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 22:59 Query about kdump_msg hook into crash_kexec() Vivek Goyal
2011-02-01 7:19 ` Américo Wang
2011-02-01 7:33 ` Eric W. Biederman
2011-02-01 7:38 ` Américo Wang
2011-02-01 8:13 ` [Patch] kexec: remove KMSG_DUMP_KEXEC (was Re: Query about kdump_msg hook into crash_kexec()) Américo Wang
2011-02-01 15:28 ` Vivek Goyal
2011-02-01 16:06 ` Jarod Wilson
2011-02-03 0:59 ` KOSAKI Motohiro
2011-02-03 2:07 ` Vivek Goyal
2011-02-03 4:53 ` KOSAKI Motohiro
2011-05-26 20:10 ` Andrew Morton
2011-05-28 1:43 ` Eric W. Biederman
2011-05-30 7:30 ` Américo Wang
2011-05-30 5:13 ` KOSAKI Motohiro
2011-05-31 21:51 ` Vivek Goyal
2011-06-09 11:00 ` KOSAKI Motohiro
2011-06-14 22:13 ` Vivek Goyal
2011-05-31 20:58 ` Seiji Aguchi
2011-05-31 21:37 ` Vivek Goyal
2011-05-31 22:24 ` Seiji Aguchi
2011-06-02 3:26 ` Eric W. Biederman [this message]
2011-06-08 0:00 ` Andrew Morton
2011-06-09 11:15 ` KOSAKI Motohiro
2011-02-03 0:55 ` Query about kdump_msg hook into crash_kexec() KOSAKI Motohiro
2011-02-03 2:05 ` Vivek Goyal
2011-02-03 4:52 ` KOSAKI Motohiro
2011-02-03 5:20 ` KOSAKI Motohiro
2011-02-04 15:00 ` Vivek Goyal
2011-03-08 1:31 ` KOSAKI Motohiro
2011-02-04 14:58 ` Vivek Goyal
2011-02-03 18:38 ` Seiji Aguchi
2011-02-03 21:13 ` Eric W. Biederman
2011-02-03 22:08 ` Seiji Aguchi
2011-02-04 2:24 ` Américo Wang
2011-02-04 2:50 ` Vivek Goyal
2011-02-04 3:28 ` Américo Wang
2011-02-04 6:40 ` KOSAKI Motohiro
2011-02-08 16:46 ` Vivek Goyal
2011-02-08 17:35 ` Eric W. Biederman
2011-02-08 19:27 ` Vivek Goyal
2011-02-08 19:58 ` Eric W. Biederman
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=m1ei3cq5gj.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=jwilson@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=seiji.aguchi@hds.com \
--cc=vgoyal@redhat.com \
--cc=xiyou.wangcong@gmail.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