From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: kexec-ml <kexec@lists.infradead.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
Date: Fri, 10 Jul 2009 15:32:09 +0900 [thread overview]
Message-ID: <4A56E069.5040907@jp.fujitsu.com> (raw)
In-Reply-To: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
Hi Ohmichi-san,
Ken'ichi Ohmichi wrote:
> Hi,
>
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
>
> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> 2nd-kernel for enabling a kdump.
I think this description is slightly wrong because kdump will be invoked
from panic, regardless of the panic_on_oops.
Maybe:
A kdump on oops is enabled if a kernel parameter "oops=panic" ...
~~~~~~~
>
> * Reference
> The discussion about this patch
> http://lists.infradead.org/pipermail/kexec/2009-July/003417.html
I'd like to quote your comment:
>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>> been changed to a NULL pointer error instead of calling crash_kexec()
>> since linux-2.6.31-rc1.
So the real problem is that kdump is not triggered by the NULL pointer oops
if !panic_on_oops, isn't it?
It seems that you should report this trouble of sysrq-c as a regression.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
> --- a/kernel/kexec.c 2009-07-08 12:30:26.000000000 +0900
> +++ b/kernel/kexec.c 2009-07-08 12:38:08.000000000 +0900
> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>
> int kexec_should_crash(struct task_struct *p)
> {
> + if (kexec_crash_image)
> + return 1;
> if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> return 1;
> return 0;
I think kexec cannot crash if there is no image, right?
Then:
if (kexec_crash_image)
return 1;
return 0;
or
return (kexec_crash_image) ? 1 : 0;
or
since crash_kexec() is nop if !kexec_crash_image,
replace all:
if (kexec_should_crash(p))
crash_kexec(reg);
at everywhere in kernel to a simple line:
crash_kexec(reg);
and remove kexec_should_crash() completely
would be better fix.
Thanks,
H.Seto
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
Cc: lkml <linux-kernel@vger.kernel.org>,
kexec-ml <kexec@lists.infradead.org>
Subject: Re: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
Date: Fri, 10 Jul 2009 15:32:09 +0900 [thread overview]
Message-ID: <4A56E069.5040907@jp.fujitsu.com> (raw)
In-Reply-To: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
Hi Ohmichi-san,
Ken'ichi Ohmichi wrote:
> Hi,
>
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
>
> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> 2nd-kernel for enabling a kdump.
I think this description is slightly wrong because kdump will be invoked
from panic, regardless of the panic_on_oops.
Maybe:
A kdump on oops is enabled if a kernel parameter "oops=panic" ...
~~~~~~~
>
> * Reference
> The discussion about this patch
> http://lists.infradead.org/pipermail/kexec/2009-July/003417.html
I'd like to quote your comment:
>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>> been changed to a NULL pointer error instead of calling crash_kexec()
>> since linux-2.6.31-rc1.
So the real problem is that kdump is not triggered by the NULL pointer oops
if !panic_on_oops, isn't it?
It seems that you should report this trouble of sysrq-c as a regression.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
> --- a/kernel/kexec.c 2009-07-08 12:30:26.000000000 +0900
> +++ b/kernel/kexec.c 2009-07-08 12:38:08.000000000 +0900
> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>
> int kexec_should_crash(struct task_struct *p)
> {
> + if (kexec_crash_image)
> + return 1;
> if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> return 1;
> return 0;
I think kexec cannot crash if there is no image, right?
Then:
if (kexec_crash_image)
return 1;
return 0;
or
return (kexec_crash_image) ? 1 : 0;
or
since crash_kexec() is nop if !kexec_crash_image,
replace all:
if (kexec_should_crash(p))
crash_kexec(reg);
at everywhere in kernel to a simple line:
crash_kexec(reg);
and remove kexec_should_crash() completely
would be better fix.
Thanks,
H.Seto
next prev parent reply other threads:[~2009-07-10 6:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-09 8:05 [PATCH] kdump: Enable kdump if 2nd-kernel is loaded Ken'ichi Ohmichi
2009-07-09 8:05 ` Ken'ichi Ohmichi
2009-07-10 6:32 ` Hidetoshi Seto [this message]
2009-07-10 6:32 ` Hidetoshi Seto
2009-07-10 7:05 ` Ken'ichi Ohmichi
2009-07-10 7:05 ` Ken'ichi Ohmichi
2009-07-10 7:52 ` Hidetoshi Seto
2009-07-10 7:52 ` Hidetoshi Seto
2009-07-13 4:33 ` [PATCH-v2] " Ken'ichi Ohmichi
2009-07-13 4:33 ` Ken'ichi Ohmichi
2009-07-13 7:48 ` Hidetoshi Seto
2009-07-13 7:48 ` Hidetoshi Seto
2009-07-13 17:06 ` Eric W. Biederman
2009-07-13 17:06 ` Eric W. Biederman
2009-07-14 2:04 ` Hidetoshi Seto
2009-07-14 2:04 ` Hidetoshi Seto
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=4A56E069.5040907@jp.fujitsu.com \
--to=seto.hidetoshi@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oomichi@mxs.nes.nec.co.jp \
/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.