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