Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-chandler"

[Hidetoshi Seto]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/