From: Jin Dongming <jin.dongming@np.css.fujitsu.com>
To: Simon Kagstrom <simon.kagstrom@netinsight.net>
Cc: LKLM <linux-kernel@vger.kernel.org>
Subject: Re: Question about kmsg_dump for OOPS
Date: Fri, 04 Dec 2009 09:54:46 +0900 [thread overview]
Message-ID: <4B185DD6.1030109@np.css.fujitsu.com> (raw)
In-Reply-To: <20091203092622.599b3814@marrow.netinsight.se>
Hi Simon
I am sorry for replying late.
Thank you for your answer and your information.
I will read the discussion and consider whether there is a better method
to resolve my problem.
Best Regards,
Jin Dongming
Simon Kagstrom wrote:
> Hi Jin!
>
> On Thu, 03 Dec 2009 12:04:46 +0900
> Jin Dongming <jin.dongming@np.css.fujitsu.com> wrote:
>
>> I have a question about kmsg_dump which needs your help.
>> The question is as following:
>> Why not put the kmsg_dump() for OOPS into oops_end() and before the branch
>> of crash_kexec()?
>>
>> The reason for the question is as following:
>> Now the kmsg_dump() for OOPS is added in oops_exit(). When OOPS happened,
>> kernel will call oops_end(). If the crash_kexec() is executed first in
>> oops_end(), the oops_exit() could not be called. And also the kmsg_dump()
>> for PANIC could not be executed. So I think that the kmsg_dump() for OOPS
>> will lose its real meaning.
>
> It would be OK to move it for my part, I understand your reasoning.
> How this is handled seems to vary a bit between architectures though.
> ARM has (arch/arm/kernel/die.c)
>
> NORET_TYPE void die(const char *str, struct pt_regs *regs, int err)
> {
> [...]
> if (panic_on_oops)
> panic("Fatal exception");
>
> oops_exit();
> [...]
>
> while x86 does (arch/x86/kernel/dumpstack.c):
>
> void __kprobes oops_end(unsigned long flags, struct pt_regs *regs, int signr)
> {
> if (regs && kexec_should_crash(current))
> crash_kexec(regs);
> [...]
> oops_exit();
> [...]
> if (in_interrupt())
> panic("Fatal exception in interrupt");
> if (panic_on_oops)
> panic("Fatal exception");
>
>
> There was some additional discussion on this a while ago in these two
> threads:
>
> http://lkml.org/lkml/2009/11/11/404
>
> http://lkml.org/lkml/2009/10/23/131
>
> where there additionally was a request to move
>
> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
>
> before kmsg_dump() and crash_kexec(). I can't immediately see any
> problem with this approach, but I'm no expert on kexec. The discussion
> didn't really conclude on this matter though.
>
> // Simon
>
>
prev parent reply other threads:[~2009-12-04 0:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-03 3:04 Question about kmsg_dump for OOPS Jin Dongming
2009-12-03 8:26 ` Simon Kagstrom
2009-12-04 0:54 ` Jin Dongming [this message]
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=4B185DD6.1030109@np.css.fujitsu.com \
--to=jin.dongming@np.css.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=simon.kagstrom@netinsight.net \
/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.