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: <20190418074552.x7bl7tr76dui64f5@pathway.suse.cz>
Date:   Thu, 18 Apr 2019 09:45:52 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Feng Tang <feng.tang@...el.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 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.

That said, I do not resist on it.

Best Regards,
Petr