On Mon, Sep 28, 2026 at 2:09 PM <[email protected]> wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > - [Medium] panic: Pre-kdump callbacks always receive NULL message in default > config
fwiw, this report seems invalid to me. > commit 8884313d127ae4b9734baebea7b4ba8dd25b38a5 > Author: Zack Rusin <[email protected]> > > crash: Notify pre-kdump callbacks before switching kernels > > Fatal x86 oopses can call crash_kexec() without reaching panic(). Run the > pre-kdump chain from __crash_kexec() as well, after finding a loaded image > under the kexec lock and capturing the original registers. > > Link: https://lore.kernel.org/r/[email protected] > > > the shared guard skips callbacks already invoked by panic(). > > [Severity: Medium] > Is this statement accurate? > > During a standard panic-triggered kdump with crash_kexec_post_notifiers=0 > (the default configuration), vpanic() calls __crash_kexec(NULL) before it > formats the panic message and calls its own explicit > panic_notify_pre_kdump(buf). > > Because __crash_kexec(NULL) runs first, won't the new > panic_notify_pre_kdump(NULL) call consume the once-per-boot atomic guard, > rather than being skipped by it? Yes, and that's intended. By default the crash-core call runs first and the late call in vpanic() is skipped. With crash_kexec_post_notifiers=1 the order is reversed. vpanic() runs the list with buf, and the crash-core call is skipped. The changelog sentence only describes the second case. > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > index 2b36aa9fade06..5d9fe9e00f39f 100644 > > --- a/kernel/crash_core.c > > +++ b/kernel/crash_core.c > [ ... ] > > @@ -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 there's an interest in fixing this false-positive in code for Sashiko (or if there are other issues that would make me respin v3) I'd just change the doc added in the first change in this series like this: - * @msg: Panic message, or NULL for direct crash-kexec entry + * @msg: Optional panic message; callbacks must tolerate NULL which, I think, would fix Sashiko here. z
smime.p7s
Description: S/MIME Cryptographic Signature
