All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH 2/2] panic: Enable to print out all printk msg in buffer
Date: Wed, 10 Apr 2019 18:12:25 +0800	[thread overview]
Message-ID: <20190410101225.gs7445svboftdcze@shbuild888> (raw)
In-Reply-To: <20190409141430.w2fulp7jnnthojrc@pathway.suse.cz>

Hi Petr,

On Tue, Apr 09, 2019 at 04:14:30PM +0200, Petr Mladek wrote:
> On Mon 2019-04-01 18:48:04, Feng Tang wrote:
> > Currently on panic, kernel will lower the loglevel and print out
> > new printk msg only. With this patch, user can configure the
> > "panic_print" to see all dmesg in buffer, some of which they may
> > have never seen due to the loglevel setting.
> > 
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> > ---
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index fb77e01..afe023e 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);
> > @@ -134,6 +135,13 @@ EXPORT_SYMBOL(nmi_panic);
> >  
> >  static void panic_print_sys_info(void)
> >  {
> > +	bool flush_all_dmesg = false;
> > +
> > +	if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
> > +		flush_all_dmesg = true;
> > +
> > +	console_flush_on_panic(flush_all_dmesg);
> 
> We should:
> 
>    + Flush the latest messages before we replay the log.
> 
>    + Show some header line before replaing the log.
> 
> 
> Therefore, I would keep console_flush_on_panic() as is.
> Then I would add:
> 
> int console_replay;
> 
> void console_replay_on_panic(void)
> {
> 	/*
> 	 * If someone else is holding the console lock, trylock will fail
> 	 * and may_schedule may be set.  Ignore and proceed to unlock so
> 	 * that messages are flushed out.  As this can be called from any
> 	 * context and we don't want to get preempted while flushing,
> 	 * ensure may_schedule is cleared.
> 	 */
> 	console_trylock();
> 	console_may_schedule = 0;
> 	console_replay = 1;
> 	console_unlock();
> }

Many thanks for the review and detailed sample codes.

Your code of moving the console_seq and console_index changing
code into concole_unlock() is much safer, which is protected by
the locl.

Initially I thought of adding a new function similar to this, but
was afraid that it is too similar to the console_flush_on_panic() :)

> 
> Then I would update cosole_unlock() with something like:
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 02ca827b8fac..14ef4e2431e7 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2386,21 +2386,32 @@ void console_unlock(void)
>  
>  	for (;;) {
>  		struct printk_log *msg;
> +		int reset_idx = 0;
>  		size_t ext_len = 0;
> -		size_t len;
> +		size_t len = 0;
>  
>  		printk_safe_enter_irqsave(flags);
>  		raw_spin_lock(&logbuf_lock);
> +
>  		if (console_seq < log_first_seq) {
>  			len = sprintf(text,
>  				      "** %llu printk messages dropped **\n",
>  				      log_first_seq - console_seq);
>  
>  			/* messages are gone, move to first one */
> +			reset_idx = 1;
> +		}
> +
> +		if (console_replay) {
> +			len += sprintf(text + len,
> +				       "Replaying the entire log:\n");
> +			reset_idx = 1;
> +			console_replay = 0;
> +		}
> +
> +		if (reset_idx) {
>  			console_seq = log_first_seq;
>  			console_idx = log_first_idx;
> -		} else {
> -			len = 0;
>  		}
>  skip:
>  		if (console_seq == log_next_seq)
> 
> 
> Finally, it can get called from panic_print_sys_info(void)
> the following way:
> 
> 	/* Replay existing messages before adding other sys info. */
> 	if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
> 		console_replay_on_panic();

Yes, it should be the first inside panic_print_sys_info().

Thanks,
Feng


  parent reply	other threads:[~2019-04-10 10:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 10:48 [PATCH 1/2] printk: Add an option to flush all messages on panic Feng Tang
2019-04-01 10:48 ` [PATCH 2/2] panic: Enable to print out all printk msg in buffer Feng Tang
2019-04-09 14:14   ` Petr Mladek
2019-04-10  1:59     ` Sergey Senozhatsky
2019-04-10  8:02       ` Petr Mladek
2019-04-10  8:16         ` Sergey Senozhatsky
2019-04-10 10:12     ` Feng Tang [this message]
2019-04-01 11:50 ` [PATCH 1/2] printk: Add an option to flush all messages on panic Mukesh Ojha
2019-04-02  2:47   ` Feng Tang
2019-04-02  2:14 ` Sergey Senozhatsky
2019-04-02  2:28   ` Feng Tang
2019-04-02  2:29     ` Sergey Senozhatsky
2019-04-09 13:41       ` Petr Mladek
2019-04-10  1:47         ` Sergey Senozhatsky
2019-04-10  2:21           ` Feng Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190410101225.gs7445svboftdcze@shbuild888 \
    --to=feng.tang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.