Thank you for your contribution! Sashiko AI review found 1 potential issue to consider: - [Medium] crash: kexec_trylock() held across panic_notify_platform() breaks kdump --
commit 27b42ef2d74e73a1aad7b08a71b2e46383b32891 Author: Zack Rusin <[email protected]> panic: Add a platform panic notifier list This commit adds a platform panic notifier list (panic_notifiers_platform_list) that runs early in vpanic() and in __crash_kexec(), along with a kernel parameter to disable it. Link: https://lore.kernel.org/r/[email protected] > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index d0bd2d0cf8990..10b4384294c2b 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c [ ... ] > @@ -139,6 +140,8 @@ void __noclone __crash_kexec(struct pt_regs *regs) > struct pt_regs fixed_regs; > > crash_setup_regs(&fixed_regs, regs); > + /* For crash paths that bypass panic() */ > + panic_notify_platform(); > crash_save_vmcoreinfo(); > machine_crash_shutdown(&fixed_regs); > crash_cma_clear_pending_dma(); [Severity: Medium] Can calling panic_notify_platform() while kexec_trylock() is held prevent kdump from running if a platform notifier callback panics? panic_notify_platform() sets done = true before invoking the notifier chain so that a callback that panics will not re-run the list when it enters vpanic(). However, when __crash_kexec() is entered directly on a crash path that bypasses panic() (such as oops_end() -> crash_kexec()), __kexec_lock is already held: crash_kexec() __crash_kexec(regs) kexec_trylock() panic_notify_platform() <callback panics> vpanic() __crash_kexec(NULL) kexec_trylock() <-- fails, skips kdump Because vpanic() never returns to the outer __crash_kexec() frame, machine_kexec() is never reached and the crash dump is lost. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
