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]

Date:	Wed, 22 Jul 2009 11:01:29 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Neil Horman <nhorman@...driver.com>
CC:	Lai Jiangshan <laijs@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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:
> None of this answers Erics question, what is it that you could do before, that
> you couldn't do now?

One is, as Ohmichi-san pointed, triggering kdump via echo c > /proc/sysrq-trigger.

In contrast to oops via SysRq-c from keyboard interrupt which results in
panic due to in_interrupt(), oops via echo-c will not become panic unless
panic_on_oops.

So in other words, we could expect same effect in both of echo-c and SysRq-c
before, but now we cannot because it depends on the panic_on_oops.
Isn't it a regression?

Whether kdump should be executed on oops (which is not panic) or not is a
separate thing.

> There are reasons to want to have a convenient 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.

Let make me sure the difference between 'crash', 'oops', and 'panic'.
At least 'oops' is not panic, as is obvious from the name of panic_on_oops.
And it seems you are using 'crash' and 'oops' in mixture.

If you mean 'crash' as 'panic', my complaint is echo-c does not panic while
SysRq-c does panic.  So if possible I'd like to suggest a change like:

 static void sysrq_handle_crash(int key, struct tty_struct *tty)
 {
-	char *killer = NULL;
-	*killer = 1;
+	panic("SysRq-triggered panic!\n");
 }

I agree that causing a real crash(panic) is better way to test crashdump than
calling the entry function of the crashdump directly, and also that opening
the path for other dump mechanisms is welcomed.

> 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.  Would it solve your issue, if we simply updated the documentation to
> illustrate how it works now?

Of course the documentation should be updated asap.
But I think the major complaint is about a difference in the behaviors of SysRq-c
and "echo c > /proc/sysrq-trigger".

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/