On (04/10/19 10:02), Petr Mladek wrote: > On Wed 2019-04-10 10:59:26, Sergey Senozhatsky wrote: > > On (04/09/19 16:14), Petr Mladek wrote: > > > We should: > > > > > > + Flush the latest messages before we replay the log. > > > > Do you mean the pending messages? When we replay the log we also should > > print "header line" and panic-cpu backtrace. So we will print panic-cpu > > oops twice > > console_flush_on_panic() is just the last resort. I believe > that the panic header and backtrace reach the console even > without it in most cases. Explicit flush before reply > would just make it consistent.
I would agree. On big systems console_sem is usually unlocked (no fbcon, no DRI, no tty writers, etc.) On desktops, laptops, and embedded device, however, killing the kernel with console_sem locked is not entirely uncommon. > The panic() message is usually the most important one for debugging. > I feel a bit uneasy that we would delay it until full replay that > might get killed from several reasons: > > + external monitoring system would force reboot > > + user might realize, e.g. after 20 minutes, that the full > log reply was probably not worth it. > > I understand that people enabling this option would most likely > wait but still. I do not see it as a big deal to repeat > the messages. Well, OK, this sounds reasonable. At the same time this option depends on panic_print, which is probably debugging option anyway and panic_print output can get a bit large and time consuming, so maybe external monitors are not part of the picture when panic_print is used. But no real objections; need to make sure that no one else, except panic, will ever use that new symbol. -ss