From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.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>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Jan Kara <jack@suse.cz>
Subject: Re: [RFC][PATCH v6 1/2] printk: Make printk() completely async
Date: Wed, 23 Mar 2016 10:24:43 +0900 [thread overview]
Message-ID: <20160323012238.GB641@swordfish> (raw)
In-Reply-To: <20160322163612.GB5522@pathway.suse.cz>
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.
- 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()
: if (!cpumask_empty(&mask))
: smp_cross_call(&mask, IPI_CPU_STOP);
:
: /* Wait up to one second for other CPUs to stop */
: timeout = USEC_PER_SEC;
: while (num_online_cpus() > 1 && timeout--)
: udelay(1);
:
: if (num_online_cpus() > 1)
: pr_warn("SMP: failed to stop secondary CPUs\n");
:
: return;
waits for one second and returns back to panic_cpu, and panic_cpu sets
oops_in_progress back to zero. simulataneously SOPT_IPIs can start arriving
to remaining CPUs. on some platforms (ARM, for instance) STOP_IPI is
: raw_spin_lock(&stop_lock);
: pr_crit("CPU%u: stopping\n", cpu);
: dump_stack();
: raw_spin_unlock(&stop_lock);
: }
:
: set_cpu_online(cpu, false);
:
: local_fiq_disable();
: local_irq_disable();
:
: while (1)
: cpu_relax();
so CPUs dump_stack()s can in theory happen when oops_in_progress is zero
and, thus, printk will try to print it by printk_kthread, which is not
something we really want to do in panic().
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;
}
or similar.
-ss
next prev parent reply other threads:[~2016-03-23 1:23 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 [this message]
2016-03-23 9:25 ` Petr Mladek
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=20160323012238.GB641@swordfish \
--to=sergey.senozhatsky.work@gmail.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=pmladek@suse.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