Re: [PATCH v1 4/4] x86/vmware: Run panic diagnostics before kdump by default

On Thu, Sep 17, 2026 at 5:07 AM Petr Mladek <[email protected]> wrote:
>
> Adding Guilherme G. Piccoli into Cc.
>
> On Tue 2026-09-08 14:07:16, Zack Rusin wrote:
> > The core panic path enters a loaded crash kernel before running kmsg
> > dumpers, so the VMware logger cannot preserve the panic in the host log.
> > Set crash_kexec_post_notifiers during VMware platform setup. setup_arch()
> > runs before ordinary core parameters are parsed, so an explicit
> > crash_kexec_post_notifiers=0 still overrides this default. The 0644
> > parameter also remains writable at runtime.
> >
> > VMware exposes no capability bit for this behavior, so the default changes
> > for every VMware guest. Running the logger first adds work to the panic
> > path and can reduce kdump reliability.
>
> AFAIK, the quality of the notifiers is varying. Running all notifiers
> might reduce the kdump reliability even more.
>
> I do not like much the hack with crash_kexec_post_notifiers. It is
> an all or nothing option.
>
> Also it was introduced as a quick hack so that users could decide
> what is more important for them. But it is not longer a "user"
> decision when some platforms enforce the ordering because they
> depend on the notifier.
>
> panic() is problematic and it is about compromises. And we need
> to balance what is important, what is safe, and what is optional.
> This is why I suggested to introduce more notifiers some time ago,
> see https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
>
> Guillermo implemented this, see
> https://lore.kernel.org/all/[email protected]/
> But it has stalled because it touched too many subsystems and it was
> hard to get an agreement.
>
> Maybe, we should start with something simple, and introduce
> one more panic notifier as a start. It might be called either:
>
>   + "panic_hypervisor_list" because "crash_kexec_post_notifiers = true"
>     seems to be primary set on hypervisors.
>
> But I would rather make it more generic and call it
>
>   + panic_pre_crash_kexec or panic_pre_kdump because there might be
>     more notifiers which are either 100% safe and useful or are worth
>     the risk before calling crash dump.
>
> We could put there x86/vmware notifiers as a start. And we could later
> move there other important notifiers.
>
> How does that sound, please?

afaict that sounds good. Keeping it to one new list and one client
should make it manageable to review (which is my biggest worry :) ).

As so the implementation: I'll drop VMware's
crash_kexec_post_notifiers default and start with one generic
panic_pre_kdump_list, with only the VMware log sender on it. The
structured crash-report hypercall (REPORTGUESTCRASH) can terminate the
VM, so it stays late and remains suppressed when a crash kernel is
loaded. Log transfer is still controlled by
kernel.vmware_record_panic_msg, with encrypted guests defaulting to
off.

I think that without that default though, x86 oops_end() can enter
crash_kexec(regs) before reaching panic(), for example with
panic_on_oops=1. To cover that path too, I'd call the chain from
__crash_kexec() after the image check and register capture, under the
existing kexec lock. A second call in vpanic(), immediately before
kmsg_dump_desc(), would cover the fallback path. And I think a
set-once guard would prevent duplicate or recursive dispatch.

That leaves CPU-stop and ordinary notifier ordering unchanged. The
logger would read the kmsg buffer directly, without invoking the other
dumpers, and would need to tolerate NMI context and other CPUs still
running. I'll keep the crash-core call in a separate patch for kdump
review, leaving other clients for follow-ups.

Does that sound good to you?

z