On Fri, 22 Feb 2019 14:09:59 +0800 Feng Tang <[email protected]> wrote:
> When kernel panic happens, it will first print the panic call stack, > then the ending msg like: > > [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception > [ 35.749975] ------------[ cut here ]------------ > > The above message are very useful for debugging. > > But if system is configured to not reboot on panic, say the "panic_timeout" > parameter equals 0, it will likely print out many noisy message like > WARN() call stack for each and every CPU except the panic one, messages > like below: > > WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 > set_task_cpu+0x183/0x190 > Call Trace: > <IRQ> > try_to_wake_up > default_wake_function > autoremove_wake_function > __wake_up_common > __wake_up_common_lock > __wake_up > wake_up_klogd_work_func > irq_work_run_list > irq_work_tick > update_process_times > tick_sched_timer > __hrtimer_run_queues > hrtimer_interrupt > smp_apic_timer_interrupt > apic_timer_interrupt It's a fairly ugly-looking patch but I am inclined to agree. The panicing CPU is spinning and blinking a LED and all CPUs have interrupts enabled and the system is known to be in a messed up state. All sorts of kernel code could emit all sorts of output in such circumstances. So a global printk-killing knob seems appropriate. Thoughts: - why do the suppression in vprintk_emit()? Doing it right at entry to printk() seems cleaner, more explicit? - Other code sites may wish to suppress all printks. Perhaps `panic_suppress_printk' should just be called `suppress_printk'?
