Messages in this thread Patch in this message | | | Date | Wed, 3 Sep 2008 12:04:23 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] [1/2] Add a SYSTEM_PANIC state |
| |
On Tue, 2 Sep 2008 15:49:22 +0200 (CEST) Andi Kleen <andi@firstfloor.org> wrote:
> --- linux.orig/include/linux/kernel.h > +++ linux/include/linux/kernel.h > @@ -248,6 +248,7 @@ extern enum system_states { > SYSTEM_POWER_OFF, > SYSTEM_RESTART, > SYSTEM_SUSPEND_DISK, > + SYSTEM_PANIC, > } system_state;
system_state is such a crock. I wonder what other random code all over the place is looking at system_state and will get unexpectedly broken by other "unrelated" changes such as this..
It's not a heck of a lot nicer, but we could do this:
--- a/kernel/panic.c~a +++ a/kernel/panic.c @@ -80,7 +80,6 @@ NORET_TYPE void panic(const char * fmt, vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf); - bust_spinlocks(0); /* * If we have crashed and we have a crash kernel loaded let it handle @@ -97,6 +96,7 @@ NORET_TYPE void panic(const char * fmt, */ smp_send_stop(); #endif + bust_spinlocks(0); atomic_notifier_call_chain(&panic_notifier_list, 0, buf); _ then test oops_in_progress down in the IPI code. This has the advantage of not introducing any additional global states and is a bit more logical, I think. Need to check whether crash_kexec() would be affected by the above change.
Bear in mind that the oops-handling code can call panic(), if panic_on_oops==1. I can't think of any adverse or special consequences of this, but it needs to be thought about.
| |