linux-kernel - Re: [PATCH v2] panic: add an option to replay all the printk message in buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190418110152.szhc3rebqzgzrhjh@pathway.suse.cz>
Date:   Thu, 18 Apr 2019 13:01:52 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Feng Tang <feng.tang@...el.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Borislav Petkov <bp@...e.de>, ying.huang@...el.com
Subject: Re: [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