Messages in this thread | | | Date | Thu, 3 Dec 2009 09:26:22 +0100 | From | Simon Kagstrom <> | Subject | Re: Question about kmsg_dump for OOPS |
| |
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
| |