public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Américo Wang" <xiyou.wangcong@gmail.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Jarod Wilson <jwilson@redhat.com>
Subject: Re: Query about kdump_msg hook into crash_kexec()
Date: Thu, 3 Feb 2011 21:50:42 -0500	[thread overview]
Message-ID: <20110204025041.GB30087@redhat.com> (raw)
In-Reply-To: <20110204022427.GA13902@cr0.redhat.com>

On Fri, Feb 04, 2011 at 10:24:27AM +0800, Américo Wang wrote:
> On Thu, Feb 03, 2011 at 05:08:01PM -0500, Seiji Aguchi wrote:
> >Hi Eric,
> >
> >Thank you for your prompt reply.
> >
> >I would like to consider "Needs in enterprise area" and "Implementation of kmsg_dump()" separately.
> >
> >(1) Needs in enterprise area
> >  In case of kdump failure, we would like to store kernel buffer to NVRAM/flush memory
> >  for detecting root cause of kernel crash.
> >
> >(2) Implementation of kmsg_dump 
> >  You suggest to review/test cording of kmsg_dump() more.
> >
> >What do you think about (1)?
> >Is it acceptable for you?
> >
> 
> For "in case of kdump fails", we can move
> KMSG_DUMP_OOPS/KMSG_DUMP_PANIC before calling crash_kexec(),
> so you can capture the log before kdump happens.

True. If the idea is to capture the logs before kdump starts saving
core, then kdump_msg() call, can be put before crash_kexec() call and
there is no need to hook into crash_kexec().

Secondly now the question of whether kdump_msg() call should be before
crash_kexec() or not because modules might want to do lots of unreliable
things, I am now split on that. Especially because of the fact that if
somebody wants it probably can use kprobe to hook into crash_kexec()
or panic() or something like that to execute its code before everything
else.

The other reason I am little split on this because in the past I have seen
kdump fail many a times either because of chipset issues or because of driver
issues etc. So though I don't like it and I want drivers to be fixed
to take care of booting in kdump environment, things not necessarily
worked as well as we expected them to and it is not hard to meet a kdump
failure.

Hence though I do not prefer it but I will not stand in the way of kdump_msg()
being called before crash_kexec() gets the control.

But we should atleast remove the hook from crash_kexec() and get rid
of additional config option (KMSG_DUMP_KEXEC).

Thanks
Vivek

  reply	other threads:[~2011-02-04  2:51 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
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 [this message]
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=20110204025041.GB30087@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jwilson@redhat.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seiji.aguchi@hds.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