Re: [PATCH v4] panic: Avoid the extra noise dmesg

From: Petr Mladek
Date: Tue Dec 11 2018 - 03:32:35 EST


On Mon 2018-12-10 10:49:22, Kees Cook wrote:
> On Mon, Dec 10, 2018 at 10:17 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > On Fri, 7 Dec 2018 17:51:19 +0800
> > Feng Tang <feng.tang@xxxxxxxxx> 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:
> >
> >
> > > Keeping the interrupt disabled will avoid the noisy message.
> > >
> > > When code runs to this point, it means user has chosed to not reboot, or
> > > do any special handling by using the panic notifier method, the only reason
> > > to enable the interrupt may be sysrq migic key and panic_blink function
> > > (though may not work even with irq enabled).
> > >
> > > So make the irq disabled by default and add a cmdline parameter
> > > "panic_keep_irq_on" to turn it on when needed.
> > >
> > > Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx>
> > >
> >
> > Acked-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
>
> I'm fine with the new boot param, but I think we need to leave it how
> it was by default: systems that want to see the blinking aren't going
> to have a screen to read about what boot param they need to add.
> Currently, we'll blink and spew extra warnings. With this patch we'll
> not blink and not spew: a headless machine will have no indication
> that a panic happened.

Just to be sure, in case, you did not follow the other long
discussion.

I had an alternative approach to switch printk() into nop at
this panic() stage. It can be restored when sysrq is triggered.
This approach allows to keep blinking and sysrq working. People
debugging the blinking would need to block this change but it
should be rare.

I do not resist on my solution. It looks a bit hacky. But it
is simple and rather straightforward.

Best Regards,
Petr