linux-kernel - Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A65B1AE.5000305@cn.fujitsu.com>
Date:	Tue, 21 Jul 2009 20:16:46 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	Neil Horman <nhorman@...driver.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Brayan Arraes <brayan@...k.com.br>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>
Subject: Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c
 handler"

Neil Horman wrote:
> On Tue, Jul 21, 2009 at 03:49:22PM +0900, Hidetoshi Seto wrote:
>> 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@...driver.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@...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
>>
>>
> None of this answers Erics question, what is it that you could do before, that
> you couldn't do now?  There are reasons to want to have a convienient way to
> crash the kernel, other than to test kdump (several distributions have augmented
> sysrq-c to do this for some time to test other previous dump mechanisms and
> features), so while its not been upstream, saying that its well known to test
> kdump without causing an oops is a bit of a misleading statement.  It seems to
> me that right now your major complaint is that the documentation is out of date,
> and you're having to do things slightly differently to get the same behavioral
> results. 


I totally agreed that we just do things slightly differently
to get the same behavioral results. And we did it as you said.

So, Actually, our problem has been solved as you said
before I send the patch.

I just thought your fix is not proper for the kernel.


> Would it solve your issue, if we simply updated the documentation to
> illustrate how it works now?
>

Also the naming should be updated.
Your Sysrq-c triggers an oops if I didn't misunderstand your fix.

Lai

---------
Quote from Documentation/sysrq.txt
"""
It is a 'magical' key combo you can hit which the kernel will
respond to regardless of whatever else it is doing, unless
it is completely locked up.
"""

We can image this condition, the kernel is close to dead,
we can't type any command to set panic_on_oops to 1.
so we try to get the kernel's core file and analyze it some day,
but sysrq-c just print something without crashdown.

How can we do now? SysRq becomes not so magical.
----------








--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/