Messages in this thread | | | Date | Wed, 17 Apr 2019 14:24:58 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH v2] panic: add an option to replay all the printk message in buffer |
| |
On Wed 2019-04-17 19:50:10, Sergey Senozhatsky wrote: > On (04/17/19 18:46), Sergey Senozhatsky wrote: > > > > Does not look too complex/ugly. > > Looks simpler than adding one more global state to the > console_unlock() printing loop. > > // Not tested at all // > > diff --git a/kernel/panic.c b/kernel/panic.c > index cd73af35ec66..50eacfc9bc7e 100644 > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -51,6 +51,7 @@ EXPORT_SYMBOL_GPL(panic_timeout); > #define PANIC_PRINT_TIMER_INFO 0x00000004 > #define PANIC_PRINT_LOCK_INFO 0x00000008 > #define PANIC_PRINT_FTRACE_INFO 0x00000010 > +#define PANIC_PRINT_ALL_PRINTK_MSG 0x00000020 > unsigned long panic_print; > > ATOMIC_NOTIFIER_HEAD(panic_notifier_list); > @@ -148,6 +149,9 @@ static void panic_print_sys_info(void) > > if (panic_print & PANIC_PRINT_FTRACE_INFO) > ftrace_dump(DUMP_ALL); > + > + if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG) > + console_flush_on_panic(CONSOLE_FLUSH_ALL);
The console must be replayed as the first thing in panic_print_sys_info(). Otherwise, the original messages are replaced by the other dumps. Especially ftrace_dump() might be pretty long.
Also the names of the function and the parameter are misleading. All messages are already flushed when this is called.
> } > > /** > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 17102fd4c136..da60a185dbbb 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -2549,6 +2549,14 @@ void console_flush_on_panic(void) > */ > console_trylock(); > console_may_schedule = 0; > + if (flush_mode == CONSOLE_FLUSH_ALL) { > + /* > + * Can be done under logbuf lock, but it's unlikely that > + * we will have any race conditions here. > + */ > + console_seq = log_first_seq; > + console_idx = log_first_idx;
I agree that it is easier. The cost is that the same messages are printed again without any explanation.
I still think that it would be convenient to write a header line. It would help to understand the log for any, even 3rd-party, reader. Also it would help to find the beginning in a very long log.
If the complexity of console_unlock() is the concern, we could refactor the code, e.g. put this "reset log" code into a separate function.
Best Regards, Petr
| |