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
next prev parent 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 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.