[RFC PATCH 1/4] panic: add a pre kdump notifier list

[Petr Mladek]

On Sat 2026-07-11 00:22:50, Bradley Morgan wrote:
> When a crash kernel is loaded, panic() jumps to it before the panic
> notifiers run. A hypervisor or firmware therefore never learns that
> the guest panicked: the Hyper-V host never receives the crash
> registers, a Google gsmi firmware log entry is dropped, a pvpanic
> device never signals the host, and an AMD SEV-SNP guest skips the
> firmware and IOMMU shutdown. Fleet alerting, availability tracking,
> and crash logging all miss the event.
> 
> The only escape hatch today is crash_kexec_post_notifiers, but it runs
> the entire legacy notifier list before the kdump. That list carries
> slow callbacks, IPMI being the obvious one because it talks to a BMC,
> so enabling it delays every crash dump on the machine. Hyper-V forces
> it on anyway and penalizes every kdump for the sake of one upcall;
> this series also removes the forcing that SEV-SNP added for the same
> reason, giving SNP hosts the normal early crash kexec back.
> 
> Add a small dedicated list that always runs before crash kexec. The
> list head stays private and registration goes through a function,
> because the callbacks on this list have a strict contract and an API
> is how you enforce one. The list lives in its own file, not in panic.c,
> so the contract can carry a MAINTAINERS entry and the existing panic
> code does not have to move.
> 
> Priorities order the list like any atomic notifier chain. The header
> documents that they are reserved for callbacks that must run last, for
> example because they may not return or because they tear down a
> transport that other callbacks still need.
> 
> The notify path walks the chain by hand and names each callback on the
> console before invoking it. Running anything before the crash kexec is
> a reliability trade, if an upcall hangs or faults and costs us the
> crash dump, the console identifies the culprit instead of leaving a
> machine that silently never rebooted into the kdump kernel. Callback
> return values are deliberately ignored, and a nested panic resumes the
> walk after the callback that was running instead of refaulting on it.

This is a long blob of text. I refuse to find the details there.
I miss a clear summary how this list is different from
atomic_notifier_chain and why we need it.

My understanting is that there two "main" differences. The new list:

  + ignores errors. But this might be achieved by requesting
    that panic() notifiers should always return 0.

  + skips already proceed notifiers during a nested panic.
    But this is a rather theoretical corner case.

IMHO, it not worth the effort.

Did I miss anything, please?

Best Regards,
Petr