Messages in this thread | | | Date | Tue, 21 Jul 2009 14:00:45 +0800 | From | Lai Jiangshan <> | Subject | Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler" |
| |
Eric W. Biederman wrote: > Lai Jiangshan <laijs@cn.fujitsu.com> writes: > >> 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. > > How does it break your tools?
Sysrq-c is known for causing a CrashDump. This fix make Sysrq-c just causing an oops. An oops in process context just kills current task and does nothing. (panic_on_oops=0)
Why we let a cleanup patch changes the kernel behavior so much?
> >> 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. > > The idea was to extend sysrq-d to also be a way of testing NULL > pointer dereferences. How is that a bad idea? >
When CONFIG_KEXEC=n, Crashdump is not available, Sysrq-c should become an invalid command.
| |