All of lore.kernel.org
 help / color / mirror / Atom feed
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

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