public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jan Kara <jack@suse.com>, Tejun Heo <tj@kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org,
	Byungchul Park <byungchul.park@lge.com>, Jan Kara <jack@suse.cz>
Subject: Re: [RFC][PATCH v6 1/2] printk: Make printk() completely async
Date: Wed, 23 Mar 2016 10:25:41 +0100	[thread overview]
Message-ID: <20160323092541.GC5522@pathway.suse.cz> (raw)
In-Reply-To: <20160323012238.GB641@swordfish>

On Wed 2016-03-23 10:24:43, Sergey Senozhatsky wrote:
> On (03/22/16 17:36), Petr Mladek wrote:
> > > -	/* cpu currently holding logbuf_lock in this function */
> > > -	static unsigned int logbuf_cpu = UINT_MAX;
> > > +	bool in_panic = console_loglevel == CONSOLE_LOGLEVEL_MOTORMOUTH;
> > 
> > I am just looking at the printk in NMI patchset and I will need to
> > deal with the panic state as well. I am not sure if this detection
> > is secure.
> > 
> > This console level is set also by kdb_show_stack()
> > and kdb_dumpregs(). I am not sure how this kdb stuff works
> > and if it affects normal kernel but...
> > 
> > Anyway, it seems that many locations detects the panic situation
> > via the variable oops_in_progress. It has another advantage
> > that it can be easily checked and we would not need any extra
> > variable here.
> 
> oops_in_progress is not my favorite global. and we can't rely on it
> in async printk.
> 
> in panic() we have
> 
>  console_verbose();
>  bust_spinlocks(1); 		<< sets to one
> 
> 	pr_emerg("Kernel panic - not syncing: %s\n", buf);
> 	smp_send_stop();
> 
>  bust_spinlocks(0);		<< sets it back to zero
> 
> 	console_flush_on_panic();
> 
> there are several issues here.
> - first, panic_cpu does not see oops_in_progress right after bust_spinlocks(0).
> thus all printk issued from panic_cpu can go via async printk.

I though that it actually could be an advantage. console_verbore() is
called also by oops_begin() and it does not need to be fatal. But you
are right that it does not need to be the righ approach.


> - second, smp_send_stop() does not guarantee that all of the CPUs received
> STOP IPI by the time it returns. on some platforms (ARM, for instance)
> smp_send_stop()

Good to know.

> so I wanted to have in printk some panic indication that once set never
> gets cleared. my proposal was
> 
> void console_panic(void)
> {
> 	printk_sync = false;
> }

Great idea. I think that we want to call this in panic() instead of
in vprintk_emit(). I mean that we should change the global flag only
when we are really going down.

Best Regards,
Petr

  reply	other threads:[~2016-03-23  9:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-21 17:25 [RFC][PATCH v6 0/2] printk: Make printk() completely async Sergey Senozhatsky
2016-03-21 17:25 ` [RFC][PATCH v6 1/2] " Sergey Senozhatsky
2016-03-22 13:11   ` Petr Mladek
2016-03-22 14:04     ` Petr Mladek
2016-03-23  0:37     ` Sergey Senozhatsky
2016-03-23  8:42       ` Sergey Senozhatsky
2016-03-23 10:04       ` Petr Mladek
2016-03-24  2:24         ` Sergey Senozhatsky
2016-03-22 16:36   ` Petr Mladek
2016-03-23  1:24     ` Sergey Senozhatsky
2016-03-23  9:25       ` Petr Mladek [this message]
2016-03-23 13:20         ` Jan Kara
2016-03-23 14:30           ` Sergey Senozhatsky
2016-03-23 14:41             ` Jan Kara
2016-03-21 17:25 ` [RFC][PATCH v6 2/2] printk: Make wake_up_klogd_work_func() async Sergey Senozhatsky
2016-03-22  6:49 ` [RFC][PATCH v6 0/2] printk: Make printk() completely async Jan Kara
2016-03-22  7:57   ` Sergey Senozhatsky
2016-03-22  8:15     ` Jan Kara
2016-04-23 19:40   ` Pavel Machek
2016-04-24  5:14     ` Sergey Senozhatsky
2016-04-24 13:35       ` Pavel Machek
2016-04-24 15:00         ` Sergey Senozhatsky

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=20160323092541.GC5522@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=byungchul.park@lge.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tj@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox