On 2026-09-28, Zack Rusin <[email protected]> wrote:
>> > @@ -139,6 +140,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)
>> >                       struct pt_regs fixed_regs;
>> >
>> >                       crash_setup_regs(&fixed_regs, regs);
>> > +                     panic_notify_pre_kdump(NULL);
>>
>> [Severity: Medium]
>> Will this cause pre-kdump notifiers to receive a NULL message pointer instead
>> of the expected panic message?
>>
>> If a system panic occurs and kexec is configured with the default setting of
>> crash_kexec_post_notifiers=0, vpanic() triggers __crash_kexec(NULL) before
>> reaching its own explicit panic_notify_pre_kdump(buf):
>>
>> kernel/panic.c:vpanic() {
>>     ...
>>     if (!_crash_kexec_post_notifiers)
>>         __crash_kexec(NULL);
>>     ...
>>     panic_notify_pre_kdump(buf);
>> }
>>
>> When this happens, __crash_kexec() will invoke panic_notify_pre_kdump() with
>> a NULL message pointer. This permanently consumes the once-per-boot guard,
>> and any callback relying on the documented msg parameter will experience
>> data loss or potential NULL dereferences, violating the API contract that
>> promises the panic message during a panic.
>
> afaict Sashiko gets tripped up here by the doc from the previous
> email. Nothing in this series dereferences the msg. The only callback
> is the VMware logger in patch 4, which ignores the argument. It reads
> the printk buffer, where vpanic() has already written the panic line.

If you are not using the argument, why are you providing it in your new
API? Just drop the argument. If any future pre_kdump panic notifiers
need additional information, they can adjust the API appropriately.

John Ogness

Reply via email to