LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Takenori Nagano <>
	Bernhard Walle <>,,,
	Andrew Morton <>
Subject: Re: [patch] add kdump_after_notifier
Date: Wed, 01 Aug 2007 04:00:48 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Takenori Nagano's message of "Wed, 01 Aug 2007 18:26:13 +0900")

Takenori Nagano <> writes:

>> No.  The problem with your patch is that it doesn't have a code
>> impact.  We need to see who is using this and why.
> My motivation is very simple. I want to use both kdb and kdump, but I think it
> is too weak to satisfy kexec guys. Then I brought up the example enterprise
> software. But it isn't a lie. I know some drivers which use panic_notifier.
> IMHO, they use only major distribution, and they has the workaround or they
> don't notice this problem yet. I think they will be in trouble if all
> distributions choose only kdump.


> BTW, I use kdb and lkcd now, but I want to use kdb and kdump. I sent a patch to
> kdb community but it was rejected. kdb maintainer Keith Owens said,

>> Both KDB and crash_kexec should be using the panic_notifier_chain, with
>> KDB having a higher priority than crash_exec.  The whole point of
>> notifier chains is to handle cases like this, so we should not be
>> adding more code to the panic routine.
>> The real problem here is the way that the crash_exec code is hard coded
>> into various places instead of using notifier chains.  The same issue
>> exists in arch/ia64/kernel/mca.c because of bad coding practices from
>> kexec.

I respectfully disagree with his opinion, as using notifier chains
assumes more of the kernel works.  Although following it's argument
to it's logical conclusion we should call crash_kexec as the very
first thing inside of panic.  Given how much state something like
bust_spinlocks messes up that might not be a bad idea.

It does make adding an alternative debug mechanism in there difficult.
Does anyone know if this also affects kgdb?

> Then I gave up to merge my patch to kdb, and I tried to send another patch to
> kexec community. I can understand his opinion, but it is very difficult to
> modify that kdump is called from panic_notifier. Because it has a reason why
> kdump don't use panic_notifier. So, I made this patch.
> Please do something about this problem.

Hmm.  Tricky.  These appear to be two code bases with a completely different
philosophy on what errors are being avoided.

The kexec on panic assumption is that the kernel is broken and we better not
touch it something horrible has gone wrong.  And this is the reason why
kexec on panic is replacing lkcd.  Because the strong assumption results
in more errors getting captured with less likely hood of messing up your

The kdb assumption appears to be that the kernel is mostly ok, and that there
are just some specific thing that is wrong.

The easiest way I can think to resolve this is for kdb to simply set
a break point at the entry point of panic() when it initializes.  Then
it wouldn't even need to be on the panic_list.  That approach would probably
even give better debug information because you would not have the effects
of bust_spinlocks to undo.

Is there some reason why kdb doesn't want to hook panic with a some
kind of break point?


  reply	other threads:[~2007-08-01 10:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 12:15 Takenori Nagano
2007-07-26 14:07 ` Bernhard Walle
2007-07-26 15:32   ` Vivek Goyal
2007-07-26 15:34     ` Bernhard Walle
2007-07-26 15:44       ` Vivek Goyal
2007-07-26 15:47         ` Bernhard Walle
2007-07-26 15:54           ` Vivek Goyal
2007-07-26 16:14             ` Bernhard Walle
2007-07-26 16:21               ` Bernhard Walle
2007-07-26 23:28             ` Takenori Nagano
2007-07-30  9:16               ` Vivek Goyal
2007-07-30 13:42                 ` Eric W. Biederman
2007-07-31  5:55                   ` Takenori Nagano
2007-07-31  6:53                     ` Eric W. Biederman
2007-08-01  9:26                       ` Takenori Nagano
2007-08-01 10:00                         ` Eric W. Biederman [this message]
2007-08-02  8:11                           ` Takenori Nagano
2007-08-02 11:28                           ` Vivek Goyal
2007-08-03  4:05                             ` Keith Owens
2007-08-03  6:25                               ` Andrew Morton
2007-08-03  6:34                                 ` Keith Owens
2007-08-03  7:37                                   ` Andrew Morton
2007-08-03  7:10                                 ` Eric W. Biederman
2007-08-05 11:07                               ` Vivek Goyal
2007-08-14  8:34                                 ` Takenori Nagano
2007-08-14  8:37                                   ` Bernhard Walle
2007-08-14  8:48                                     ` Takenori Nagano
2007-08-14  8:53                                       ` Bernhard Walle
2007-08-14 13:24                                     ` Vivek Goyal
2007-08-16  9:26                                       ` Takenori Nagano
2007-08-16  9:45                                         ` Bernhard Walle
2007-08-17 10:56                                         ` Vivek Goyal
2007-08-21  7:45                                           ` Takenori Nagano
2007-08-23  3:52                                             ` Vivek Goyal
2007-08-21 13:18                                           ` Jay Lan
2007-08-21 13:21                                             ` Bernhard Walle
2007-08-23  3:56                                             ` Vivek Goyal
2007-08-23 17:34                                               ` Jay Lan

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [patch] add kdump_after_notifier' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).