On Fri, Jun 26, 2026 at 12:23:48PM +0200, Petr Mladek 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.
Yep.
>
> > 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.
Agree :)
> 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.
When initially reviewing V2's 4th patch, I thought about the
'panic_this_cpu_backtrace_printed', but it's a local variable which
records the state.
> 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.
IIUC, panic case is kind of special, as it has to separate the
'sys_info()' op in different stage. Can we do a merge in the start
of vpanic() by:
panic_print = panic_print ?: kernel_si_mask;
as a addon patch ?
Thanks,
Feng
> I am going to think more about it.
>
> Please, do not send v4 until the discussion settles!
>
> Best Regards,
> Petr
