Messages in this thread | | | Date | Thu, 18 Apr 2019 09:00:14 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v2] panic: add an option to replay all the printk message in buffer |
| |
On (04/17/19 23:18), Feng Tang wrote: > > > +++ 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; > > This is very similar to my V1 patch :), excepted I used a bool > as the parameter.
Yes it is :)
I will reply to Petr's and Feng's email.
> > 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. > > My thought is, the replay is only a debug option and disabled by default, > so when user specifically enable the bit of PANIC_PRINT_ALL_PRINTK_MSG, > the whole replay of printk msg should be expected.
I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite specific one. So people who ask the kernel to PANIC_PRINT_ALL_PRINTK_MSG they know what they are doing, and we probably will not cofuse anyone. After all, we don't print any headers when we ftrace_dump() or imitate sysrq via sysrq_timer_list_show(), or for any other panic_print_sys_info() printouts. So it's OK to just do the simple thing for PANIC_PRINT_ALL_PRINTK_MSG.
-ss
| |