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]

Date:   Wed, 17 Apr 2019 23:18:17 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Petr Mladek <pmladek@...e.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 Wed, Apr 17, 2019 at 02:24:58PM +0200, Petr Mladek wrote:
> 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;

This is very similar to my V1 patch :), excepted I used a bool
as the parameter.

> 
> 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.

Thanks,
Feng

> 
> 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