Re: [PATCH v3 2/3] s390: Implement arch_do_panic

[Heiko Carstens <hca@linux.ibm.com>]

On Thu, Jul 30, 2026 at 03:15:31PM +0200, Mete Durlu wrote:
> On 30/07/2026 13:54, Heiko Carstens wrote:
> > Question: why is it desirable that panic_timeout takes precedence? The result
> > of this change is quite surprising: if anybody (e.g. a distribution) sets
> > CONFIG_PANIC_TIMEOUT to a non-zero value this completely breaks "on_panic"
> > behaviour on s390.
> 
> panic timeout can be set during boot or compile time as you said, so it
> can be used to determine what will happen to a system if it panics
> during boot along with after boot. Since panic timeout covers a larger
> area I thought it should get precedence.
> Being able to choose what will happen on panic before boot is a super
> power IMO and would help immensely if one would like to boot an untested
> kernel via kexec for example.

Wouldn't it then not make more sense to add an s390 specific kernel command
line parameter which _disables_ the notifier entirely, and then you get your
panic_timeout working?

Then you have to explicitely state what you want and don't get suprised by
subtle semantic changes.

> > I could understand if this change would result in a larger timeout and
> > additional information being printed, but not that it breaks existing and
> > actually designed and desired behaviour.
> 
> For that to happen users have to "misconfigure" the system and try to
> use both panic_timeout and a custom "on_panic" action. The same goes for
> kdump, when kdump is configured "on_panic" actions are ignored silently
> and system always dumps on panic.

This is really not the same. If setting panic_timeout would disable something
else that would be surprising at least, especially since it never did before.