mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH printk v2 08/11] panic: Add atomic write enforcement to warn/panic
Date: Wed, 27 Sep 2023 14:02:17 +0200	[thread overview]
Message-ID: <ZRQZycM9uTAnxn8C@alley> (raw)
In-Reply-To: <20230919230856.661435-9-john.ogness@linutronix.de>

On Wed 2023-09-20 01:14:53, John Ogness wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Invoke the atomic write enforcement functions for warn/panic to
> ensure that the information gets out to the consoles.
> 
> For the panic case, add explicit intermediate atomic flush
> calls to ensure immediate flushing at important points.
> Otherwise the atomic flushing only occurs when dropping out of
> the elevated priority, which for panic may never happen.

It would be great to avoid the need for the explicit flushes
except for the final unsafe one. Otherwise, we would play
another Whack-a-mole game. People would report that
panic() failed and they needed to add another explicit flush
to find the culprit...

> It is important to note that if there are any legacy consoles
> registered, they will be attempting to directly print from the
> printk-caller context, which may jeopardize the reliability of
> the atomic consoles. Optimally there should be no legacy
> consoles registered.

> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -275,6 +275,7 @@ static void panic_other_cpus_shutdown(bool crash_kexec)
>   */
>  void panic(const char *fmt, ...)
>  {
> +	enum nbcon_prio prev_prio;
>  	static char buf[1024];
>  	va_list args;
>  	long i, i_next = 0, len;
> @@ -322,6 +323,8 @@ void panic(const char *fmt, ...)
>  	if (old_cpu != PANIC_CPU_INVALID && old_cpu != this_cpu)
>  		panic_smp_self_stop();
>  
> +	prev_prio = nbcon_atomic_enter(NBCON_PRIO_PANIC);
> +

It would make sense to flush nbcon consoles the safe way
at this point before we allow dangerous games for legacy
consoles via bust_spinlock().

>  	console_verbose();
>  	bust_spinlocks(1);
>  	va_start(args, fmt);
> @@ -382,6 +385,8 @@ void panic(const char *fmt, ...)
>  	if (_crash_kexec_post_notifiers)
>  		__crash_kexec(NULL);
>  
> +	nbcon_atomic_flush_all();

There should be one more safe flush after dump_stack() just
in case the kexec fails. The legacy consoles also tried
to flush the consoles in each called printk().

...

I do not want to review or comment each added or needed
nbcon_atomic_flush_all(). I hope that they won't be needed
in the end.

Best Regards,
Petr

  reply	other threads:[~2023-09-27 12:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 23:08 [PATCH printk v2 00/11] wire up nbcon atomic printing John Ogness
2023-09-19 23:08 ` [PATCH printk v2 01/11] printk: Make console_is_usable() available to nbcon John Ogness
2023-09-22  8:33   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 02/11] printk: Let console_is_usable() handle nbcon John Ogness
2023-09-22  8:37   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 03/11] printk: Add @flags argument for console_is_usable() John Ogness
2023-09-22  8:41   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 04/11] printk: nbcon: Provide functions to mark atomic write sections John Ogness
2023-09-22  9:33   ` Petr Mladek
2023-09-25  9:25     ` John Ogness
2023-09-25 16:04       ` Petr Mladek
2023-10-05 12:51         ` John Ogness
2023-10-06 12:51           ` panic context: was: " Petr Mladek
2023-10-06 12:53           ` Petr Mladek
2023-10-08 10:13             ` John Ogness
2023-10-09 15:32               ` Petr Mladek
2023-10-10 16:02                 ` John Ogness
2023-10-16  8:58               ` Dave Young
2023-10-16 10:09                 ` John Ogness
2023-10-06 15:52           ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 05/11] printk: nbcon: Provide function for atomic flushing John Ogness
2023-09-22 12:32   ` Petr Mladek
2023-09-25 11:11     ` John Ogness
2023-09-19 23:08 ` [PATCH printk v2 06/11] printk: nbcon: Wire up nbcon console " John Ogness
2023-09-22 17:41   ` Petr Mladek
2023-09-25 13:37     ` John Ogness
2023-09-26 12:14       ` Petr Mladek
2023-10-05 13:59         ` John Ogness
2023-09-19 23:08 ` [PATCH printk v2 07/11] printk: nbcon: Wire up nbcon into console_flush_all() John Ogness
2023-09-26 11:34   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 08/11] panic: Add atomic write enforcement to warn/panic John Ogness
2023-09-27 12:02   ` Petr Mladek [this message]
2023-09-19 23:08 ` [PATCH printk v2 09/11] panic: Add atomic write enforcement to oops John Ogness
2023-09-19 23:36   ` John Ogness
2023-09-20 13:28   ` Andy Shevchenko
2023-09-20 14:20     ` John Ogness
2023-09-20 14:45       ` Andy Shevchenko
2023-09-27 13:15   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 10/11] rcu: Add atomic write enforcement for rcu stalls John Ogness
2023-09-27 15:00   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 11/11] lockdep: Add atomic write enforcement for lockdep splats John Ogness
2023-09-29  8:31   ` Petr Mladek

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=ZRQZycM9uTAnxn8C@alley \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=gpiccoli@igalia.com \
    --cc=john.ogness@linutronix.de \
    --cc=jpoimboe@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®