Messages in this thread | | | Date | Tue, 21 Jul 2009 15:49:22 +0900 | From | Hidetoshi Seto <> | Subject | Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler" |
| |
Lai Jiangshan wrote: > 1) This fix breaks our tools. > This fix changes the ABI. panic_on_oops is default 0, > and a lots system do not specify the boot option "panic", > thus, Sysrq-c will not cause CrashDump(Kdump) as expected. > > 2) When CONFIG_KEXEC=n, Sysrq-c should become an invalid > command like Sysrq-D(CONFIG_LOCKDEP, show-all-locks). > But this fix makes it a valid command and let it do a > hazard thing: cause a page fault(NULL dereference) in kernel. > > So, we revert this fix. > > |commit d6580a9f15238b87e618310c862231ae3f352d2d > |Author: Neil Horman <nhorman@tuxdriver.com> > |Date: Wed Jun 17 16:28:17 2009 -0700 > > | kexec: sysrq: simplify sysrq-c handler > > | Currently the sysrq-c handler is bit over-engineered. Its behavior is > | dependent on a few compile time and run time factors that alter its > | behavior which is really unnecessecary. > > | If CONFIG_KEXEC is not configured, sysrq-c, crashes the system with a NULL > | pointer dereference. If CONFIG_KEXEC is configured, it calls crash_kexec > | directly, which implies that the kexec kernel will either be booted (if > | its been previously loaded), or it will simply do nothing (the no kexec > | kernel has been loaded). > > | It would be much easier to just simplify the whole thing to dereference a > | NULL pointer all the time regardless of configuration. That way, it will > | always try to crash the system, and if a kexec kernel has been loaded into > | reserved space, it will still boot from the page fault trap handler > | (assuming panic_on_oops is set appropriately). > > > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> > ---
FYI, this problem has already pointed by Ohmichi-san and this will be an another patch for the following discussion: http://lists.infradead.org/pipermail/kexec/2009-July/003433.html You can find my sloppy memo in: http://lists.infradead.org/pipermail/kexec/2009-July/003443.html
I agree with you that SysRq-'c' is well known as for 'C'rashdump, and it is not expected as 'C'rash without dump.
Thanks, H.Seto
| |