linux-kernel - Re: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.

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] [day] [month] [year] [list]

Message-ID: <4A5BE7B5.7080500@jp.fujitsu.com>
Date:	Tue, 14 Jul 2009 11:04:37 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>,
	kexec-ml <kexec@...ts.infradead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.

Eric W. Biederman wrote:
> The Documentation for sysrq-c certainly needs to be updated.

No doubt about it.

> If I am doing development on a system I like oops's.  All of the
> information and nothing goes down.  I can get at /proc/kcore etc.
> 
> In a setting where I can't be Johnny on the spot and look at
> things a core dump is probably the best I can get.  In that scenario
> panic_on_oops sounds good.
> 
> As I read the current check it reads:
> If we are going to panic and not oops || panic_on_oops
> 	kexec_should_crash = true;
> 
> Which seems a very reasonable implementation of policy.

If I understand it,

a) panic
b) oops
c) SysRq (from keyboard interrupt)
d) echo c > /proc/sysrq-trigger

   a      b      c      d
common, w/o CONFIG_KEXEC:
 panic  oops   panic   oops  :
 panic  panic  panic   panic : w/ panic_on_oops

A) 2.6.30 + CONFIG_KEXEC:
 panic  oops   -       -     : w/o kdump-image
 panic  panic  -       -     : w/o kdump-image w/ panic_on_oops
 kdump  oops   kdump   kdump : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

B) 2.6.31-rc1 + CONFIG_KEXEC:
 panic  oops   panic   oops  : w/o kdump-image
 panic  panic  panic   panic : w/o kdump-image w/ panic_on_oops
 kdump  oops   kdump   oops  : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

C) After this patch + CONFIG_KEXEC:
 panic  oops   panic   oops  : w/o kdump-image
 panic  panic  panic   panic : w/o kdump-image w/ panic_on_oops
 kdump  kdump  kdump   kdump : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

Ohmichi-san pointed "oops on d) with kdump-image" in B) and suggested
it should be "kdump."
And Eric pointed "kdump on b) without panic_on_oops" in C) and requested
it should be "oops."
(Plus, IMHO, "oops on d) without panic_on_oops" should be "panic.") 

... Right?

Then as I mentioned, use panic in sysrq would be one of solutions.
Are there any better fix?


Thanks,
H.Seto

--
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/