All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@linux.ibm.com>
To: Bradley Morgan <include@grrlz.net>
Cc: Mete Durlu <meted@linux.ibm.com>,
	agordeev@linux.ibm.com, akpm@linux-foundation.org,
	andreas@gaisler.com, borntraeger@linux.ibm.com,
	davem@davemloft.net, gor@linux.ibm.com, hca@linux.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	pmladek@suse.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 2/3] s390: Implement arch_do_panic
Date: Tue, 28 Jul 2026 13:40:18 +0200	[thread overview]
Message-ID: <yt9dqzknxrz1.fsf@linux.ibm.com> (raw)
In-Reply-To: <C84A503B-3DBE-4982-A124-F3702BF9EB36@grrlz.net>

Bradley Morgan <include@grrlz.net> writes:

> On 28 July 2026 11:43:17 BST, Mete Durlu <meted@linux.ibm.com> wrote:
>>On 27/07/2026 15:01, Bradley Morgan wrote:
>>
>>Hi Bradley,
>>
>>>> This now means that the panic_timeout value takes precedence over user
>>>> defined on_panic behavior.
>>> 
>>> this is the part i want to poke at. distros routinely ship panic=N on
>>> the cmdline. with this change, anyone who configured on_panic=dump on
>>> such a system silently stops getting dumps, because
>>> emergency_restart() runs first and never returns. a reboot instead of
>>> the dump you explicitly asked for is strictly worse. if you and Sven
>>> want that semantic, fine, but spell it out properly and give the s390
>>> docs for on_panic a line about the new precedence.
>>
>>FWICT, there is no mention of shutdown actions in kernel documentation.
>>s390's user documentation is a different story. I agree it should be
>>documented on Linux on IBM systems documentation.
>>
>>I'd argue that specifying both on_panic=dump and panic=N (N>0) is
>>a configuration error, but maybe a pr_warn() could be added to the
>>when on_panic=dump is configured with panic=N is set. That could
>>hint what is wrong if anyone investigating dmesg and trying to
>>figure out why system didn't dump.
>>
>
>
> hey, sorry I'm out, so I can't do the most massive think ever, and I may
> embarrass myself, heh.
>
> I think a BUG would be sufficient, we would want to shut down the system
> with said bug, I know about panic on warn, but sometimes that's not always
> enabled, something like a BUG would be good, what do you think?

Err... No. You don't want to make a mistake while updating the kernel
panic parameters just to figure out that on the next boot the kernel just BUGs()
because of that. There are of course lots of reasons why changing the kernel
command line could end up in a non-bootable system but this one would
be ridiculous.

  reply	other threads:[~2026-07-28 11:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 10:36 [PATCH v2 0/3] Introduce arch_do_panic Mete Durlu
2026-07-27 10:36 ` [PATCH v2 1/3] panic: " Mete Durlu
2026-07-27 10:43   ` sashiko-bot
2026-07-27 12:59   ` Bradley Morgan
2026-07-28 10:13     ` Mete Durlu
2026-07-27 10:36 ` [PATCH v2 2/3] s390: Implement arch_do_panic Mete Durlu
2026-07-27 10:52   ` sashiko-bot
2026-07-27 13:01   ` Bradley Morgan
2026-07-28 10:43     ` Mete Durlu
2026-07-28 11:02       ` Bradley Morgan
2026-07-28 11:40         ` Sven Schnelle [this message]
2026-07-28 11:43           ` Bradley Morgan
2026-07-27 10:36 ` [PATCH v2 3/3] sparc: " Mete Durlu
2026-07-27 10:49   ` sashiko-bot
2026-07-27 13:02   ` Bradley Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yt9dqzknxrz1.fsf@linux.ibm.com \
    --to=svens@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=include@grrlz.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=meted@linux.ibm.com \
    --cc=pmladek@suse.com \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.