All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.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: Fri, 4 Feb 2011 10:00:47 -0500	[thread overview]
Message-ID: <20110204150047.GC32190@redhat.com> (raw)
In-Reply-To: <20110203141850.93C2.A69D9226@jp.fujitsu.com>

On Thu, Feb 03, 2011 at 02:20:53PM +0900, KOSAKI Motohiro wrote:
> > AFAIK, kexec is used sneak rebooting way when the system face unexpected
> > scenario on some devices. (Some embedded is running very long time, then 
> > it can't avoid memory bit corruption. all of reset is a last resort. 
> > and a vendor gather logs at periodically checkback).
> > 
> > The main purpose of to introduce KMSG_DUMP_KEXEC is to be separate it
> > from KMSG_DUMP_PANIC. At kmsg_dump() initial patch, KMSG_DUMP_PANIC 
> > is always called both kdump is configured or not. But it's no good idea
> > the same log is to be appeared when both kexec was successed and failured.
> > Moreover someone don't want any log at kexec phase. They only want logs
> > when real panic (ie kexec failure) route. Then, I've separated it to two.
> > Two separated argument can solve above both requreiment.
> 
> A bit additional explanation, An original patch have kmsg_dump(KMSG_DUMP_PANIC)
> callsite at following point. I didn't think it makes either embedded or 
> kdump folks happiness. Thus I moved it after crash_kexec().
> 
> 
> ---------------------------------------------------------------------
> @@ -74,6 +75,7 @@ NORET_TYPE void panic(const char * fmt, ...)
>         dump_stack();
>  #endif
> 
> +       kmsg_dump(KMSG_DUMP_PANIC);
>         /*
>          * If we have crashed and we have a crash kernel loaded let it handle
>          * everything else.
>          * Do we want to call this before we try to display a message?
>          */
>         crash_kexec(NULL);
> ---------------------------------------------------------------------

And I think to compensate for that somebody introduced additional
kmsg_dump(KEXEC) call inside crash_kexec() and put it under CONFIG
option so that one can change the behavior based on config options.

I think this makes the logic somewhat twisted and an unnecessary call
inside crash_kexec(). So until and unless there is a strong reason we
can get rid of KEXEC event and move kmsg_dump call before crash_kexec()
for now and see how does it go, IMHO.

Vivek

  reply	other threads:[~2011-02-04 15:00 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 [this message]
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=20110204150047.GC32190@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 \
    /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.