From: Bradley Morgan <include@grrlz.net>
To: akpm@linux-foundation.org
Cc: baoquan.he@linux.dev, pmladek@suse.com,
feng.tang@linux.alibaba.com, gregkh@linuxfoundation.org,
arnd@arndb.de, corbet@lwn.net, rdunlap@infradead.org,
gpiccoli@igalia.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, include@grrlz.net
Subject: [RFC PATCH 0/4] panic: a pre kdump notifier list for hypervisor upcalls
Date: Sat, 11 Jul 2026 00:22:49 +0000 [thread overview]
Message-ID: <20260711002253.1115-1-include@grrlz.net> (raw)
When a crash kernel is loaded, panic() jumps to it before the panic
notifiers run, unless crash_kexec_post_notifiers is set. So the
hypervisor or firmware never finds out the guest panicked. Hyper-V
doesn't get the crash registers, gsmi drops its firmware log entry,
pvpanic stays silent, SEV-SNP skips its firmware and IOMMU shutdown.
Whatever's watching the machine, the host, the BMC, fleet, sees a
clean reboot instead of a crash.
The only way around it today is crash_kexec_post_notifiers, but that
runs the whole legacy notifier list before the kdump. That list has
slow callbacks in it, IPMI being the obvious one since it talks to a
BMC, so turning it on slows down every crash dump on the box. Hyper-V
turns it on anyway and eats the cost for one callback. SNP did the
same.
This adds a separate list that runs before the crash kexec no matter
what. Callbacks on it have to follow a contract: no locks, no
allocation, no sleeping, other CPUs may still be running, and it has
to tolerate being entered again if the panic path itself panics. The
list head is private and you register through a function, because
that's how you make people follow the contract. Priorities order it
like any notifier chain. It lives in its own file because it's not
panic code, just a notifier chain vpanic() calls once, and the custom
walk it needs doesn't belong in the generic notifier API either. A
separate file is also the only thing a MAINTAINERS entry can scope a
reviewer to.
Running anything before the crash kexec is a reliability trade. If an
upcall hangs or faults and costs the dump, you want to know which one
did it, so the notify path walks the chain itself and prints each
callback's name on the console before calling it. Return values are
ignored. A nested panic picks up the walk after the callback that was
running, instead of re-faulting on it.
This is the minimum: the list, the hook in the panic path, one driver
converted so there's a real user, and the MAINTAINERS entry. pvpanic
is the first one. Its callback is a self contained upcall that already
takes its lock as a trylock, so it fits the contract as is. The rest
(Hyper-V, Xen, gsmi, SNP) come in a follow on series. gsmi needs a
rework to a trylock because its old deadlock guard assumed the other
CPUs were stopped, which isn't true on this list. Once SNP's notifier
is on the new list, the crash_kexec_post_notifiers forcing in
snp_rmptable_init() goes away and SNP gets the early crash kexec back.
Hyper-V keeps its forcing for now because its kmsg dump pass also needs
to run before kdump. The register report just doesn't depend on it
anymore.
IPMI stays out. Its panic handling assumes the other CPUs have been
stopped, and poking a BMC before the crash kexec would slow down every
kdump on any box with a BMC. It stays on the legacy list, where kdump
skips it like before.
The legacy list, its position in the panic path and
crash_kexec_post_notifiers itself are untouched, so the remaining
registrants see zero change and nothing is renamed.
This is on purpose. Piccoli's 2022 series tried to classify every
panic notifier and the list split didn't go in. This does the one piece
that fixes the kdump versus hypervisor conflict and stops.
One alternative is splitting the legacy list by priority and calling the
high priority half before the crash kexec. That can't do what this list
does. The walk prints each callback's name on the console before it runs,
and it ignores return values. atomic_notifier_call_chain can't do
either. It honors NOTIFY_STOP_MASK, so one callback can halt the pass
and lose every upcall after it. The walk also resumes past the faulting
callback on a nested panic and runs under RCU instead of the atomic
spinlock. Getting this behavior under a priority split means pushing a
custom walk into the generic notifier API, which is more invasive than
a file.
Build tested on arm64.
Bradley Morgan (4):
panic: add a pre kdump notifier list
panic: run the pre kdump list before crash kexec
misc/pvpanic: notify the host on the pre kdump list
MAINTAINERS: add an entry for the pre kdump notifier list
Documentation/admin-guide/kernel-parameters.txt | 3 ++
MAINTAINERS | 6 +++
drivers/misc/pvpanic/pvpanic.c | 5 +-
include/linux/panic_notifier.h | 18 +++++++
kernel/Makefile | 2 +-
kernel/panic.c | 7 +++
kernel/panic_notifiers.c | 65 +++++++++++++++++++++++++
7 files changed, 102 insertions(+), 4 deletions(-)
create mode 100644 kernel/panic_notifiers.c
--
2.53.0
next reply other threads:[~2026-07-11 0:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 0:22 Bradley Morgan [this message]
2026-07-11 0:22 ` [RFC PATCH 1/4] panic: add a pre kdump notifier list Bradley Morgan
2026-07-11 0:22 ` [RFC PATCH 2/4] panic: run the pre kdump list before crash kexec Bradley Morgan
2026-07-11 0:22 ` [RFC PATCH 3/4] misc/pvpanic: notify the host on the pre kdump list Bradley Morgan
2026-07-11 0:22 ` [RFC PATCH 4/4] MAINTAINERS: add an entry for the pre kdump notifier list 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=20260711002253.1115-1-include@grrlz.net \
--to=include@grrlz.net \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baoquan.he@linux.dev \
--cc=corbet@lwn.net \
--cc=feng.tang@linux.alibaba.com \
--cc=gpiccoli@igalia.com \
--cc=gregkh@linuxfoundation.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox