On June 26, 2026 11:23:48 AM GMT+01:00, Petr Mladek <[email protected]> wrote: >On Thu 2026-06-25 15:25:58, Bradley Morgan wrote: >> panic_other_cpus_shutdown() handles SYS_INFO_ALL_BT before stopping the >> other CPUs. Do not ask sys_info() to handle that bit again later in the >> panic path. >> >> Use sys_info_with_filter() so panic_print=all_bt does not request more >> output after the CPUs are stopped. >> >> Fixes: a9af76a78760 ("watchdog: add sys_info sysctls to dump sys info on >system lockup") >> Cc: [email protected] >> Signed-off-by: Bradley Morgan <[email protected]> >> --- >> kernel/panic.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/panic.c b/kernel/panic.c >> index 213725b612aa..eb842823df61 100644 >> --- a/kernel/panic.c >> +++ b/kernel/panic.c >> @@ -680,7 +680,7 @@ void vpanic(const char *fmt, va_list args) >> */ >> atomic_notifier_call_chain(&panic_notifier_list, 0, buf); >> >> - sys_info(panic_print); >> + sys_info_with_filter(panic_print, SYS_INFO_ALL_BT); > >Hmm, this prevents printing backtraces from all CPUs completely. >But what if they were not printed? > >They might be printed by: > >static void panic_other_cpus_shutdown(bool crash_kexec) >{ > if (panic_print & SYS_INFO_ALL_BT) > panic_trigger_all_cpu_backtrace(); > >[...] >} > >But it checks only "panic_print" variable. It won't do anything >when (panic_print == 0). > >In this case, we might still want to print the backraces when >SYS_INFO_ALL_BT is set in kernel_si_info. > >> kmsg_dump_desc(KMSG_DUMP_PANIC, buf); > >Of course, we might fix panic_other_cpus_shutdown() to check also >kernel_si_info. > >But it all becomes very hairy. We have several levels: > > + watchdog-all_bt-specific option, e.g. sysctl_hardlockup_all_cpu_backtrace > > + watchdog-specific si_info preferences, e.g. hardlockup_si_mask > > + panic-specific si_info: panic_print > > + universal fallback for any layer: kernel_si_info > >Now, we try to check all these variables back and forth to >trigger all backtraces or to avoid triggering them. >And it clearly does not work well and the code is more and more >hairy. > >I think about another approach. The word "waterfall" comes to my mind. >Instead of checking all the settings back and forth, let's process >each setting one by one and just remember what has been done and >skip this in the next level. > >All the si_info actions seems to dump a global system state. >So, it would make sense to remember the state in a global variable >even when it might be modified by more CPUs in parallel.
Not a bad idea. >I am going to think more about it. > >Please, do not send v4 until the discussion settles! I'll hold on V4. When you've finished discussing, could I have your suggested patch? if I think there is issues. I'll fix it. >Best Regards, >Petr > Thanks!
