From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Neil Horman <nhorman@tuxdriver.com>,
Vivek Goyal <vgoyal@redhat.com>,
Brayan Arraes <brayan@yack.com.br>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler"
Date: Tue, 21 Jul 2009 14:00:45 +0800 [thread overview]
Message-ID: <4A65598D.7020808@cn.fujitsu.com> (raw)
In-Reply-To: <m1d47vnoq6.fsf@fess.ebiederm.org>
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.
next prev parent reply other threads:[~2009-07-21 6:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-20 12:46 [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler" Lai Jiangshan
2009-07-20 19:22 ` Eric W. Biederman
2009-07-20 21:16 ` Neil Horman
2009-07-21 6:46 ` Lai Jiangshan
2009-07-21 22:18 ` Eric W. Biederman
2009-07-21 6:00 ` Lai Jiangshan [this message]
2009-07-21 6:56 ` Eric W. Biederman
2009-07-21 6:49 ` Hidetoshi Seto
2009-07-21 11:08 ` Neil Horman
2009-07-21 12:16 ` Lai Jiangshan
2009-07-22 2:01 ` Hidetoshi Seto
2009-07-22 11:10 ` Neil Horman
2009-07-22 13:42 ` Vivek Goyal
2009-07-22 19:38 ` Neil Horman
2009-07-23 1:10 ` Hidetoshi Seto
2009-07-23 1:09 ` Hidetoshi Seto
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=4A65598D.7020808@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=brayan@yack.com.br \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=vgoyal@redhat.com \
/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.