lkml.org 
[lkml]   [2019]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] panic: add an option to replay all the printk message in buffer
On Thu 2019-04-18 17:00:44, Feng Tang wrote:
> Hi Petr,
>
> On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> > On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > > 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.
> >
> > The following functions are currently called from panic_print_sys_info():
> >
> > + show_state():
> > printk(KERN_INFO
> > " task PC stack pid father\n");
> > + show_mem():
> > printk("Mem-Info:\n");
> >
> > + sysrq_timer_list_show()
> > no global header; but each section can be easily distinguished
> > because there are several static strings that explains the
> > content
> >
> > + debug_show_all_locks()
> > pr_warn("\nShowing all locks held in the system:\n");
> >
> > + ftrace_dump():
> > printk(KERN_TRACE "Dumping ftrace buffer:\n");
> >
> >
> > The person that enabled the debugging option might know what it did
> > when it process the log the very same day. It might be less clear
> > for others reading the log.
> >
> > Also it still might be convenient to find the beginning easily.
> > Or it might help to orientate when several test runs
> > (over night test) are squashed in a single file. I see
> > such logs pretty often.
>
> Thanks for checking all the info. For the note, how about adding
> something like this inside panic_print_sys_info()?
>
> if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG) {
> printk("\nprintk: will replay all the messages in buffer:\n");
> console_flush_on_panic(CONSOLE_FLUSH_ALL);
> }

This will store the message at the end of the buffer. It will repeat
the message once again when replaying the log. I personally think
that it is worse than printing nothing.


> If you are all fine with it, I'll go post a v3, thanks,

I suggest to wait few days. We might get opinion from someone
else...

Then sent whatever approach makes most sense to you. In fact, you
are the 3rd person in this triangle. I believe that we will
respect it. Last many mails are just a bike shedding.

Just one thing. Please, use "replay" in the function or parameter
name. The effect of console_flush_on_panic(CONSOLE_FLUSH_ALL)
is really hard to guess from the name.

Best Regards,
Petr

\
 
 \ /
  Last update: 2019-04-18 13:02    [W:0.062 / U:19.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site