From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Breno Leitao <leitao@debian.org>, Mike Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH printk v1 1/1] printk: nbcon: Allow unsafe write_atomic() for panic
Date: Wed, 17 Sep 2025 14:53:26 +0206 [thread overview]
Message-ID: <848qidw8ip.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <aMl8xX9QCM9jslLH@pathway.suse.cz>
On 2025-09-16, Petr Mladek <pmladek@suse.com> wrote:
>> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
>> index 646801813415..8c2966b85ac3 100644
>> --- a/kernel/printk/nbcon.c
>> +++ b/kernel/printk/nbcon.c
>> @@ -972,14 +972,18 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
>> /*
>> * This function should never be called for consoles that have not
>> * implemented the necessary callback for writing: i.e. legacy
>> - * consoles and, when atomic, nbcon consoles with no write_atomic().
>> + * consoles and, when atomic, nbcon consoles with no write_atomic()
>> + * or an unsafe write_atomic() without allowing unsafe takeovers.
>> * Handle it as if ownership was lost and try to continue.
>> *
>> * Note that for nbcon consoles the write_thread() callback is
>> * mandatory and was already checked in nbcon_alloc().
>> */
>> - if (WARN_ON_ONCE((use_atomic && !con->write_atomic) ||
>> - !(console_srcu_read_flags(con) & CON_NBCON))) {
>> + if (WARN_ON_ONCE(!(console_srcu_read_flags(con) & CON_NBCON) ||
>> + (use_atomic &&
>> + (!con->write_atomic ||
>> + (!ctxt->allow_unsafe_takeover &&
>> + (console_srcu_read_flags(con) & CON_NBCON_ATOMIC_UNSAFE)))))) {
>
> The condition seems to be correct. But it is evil. I wonder whether
> it would make sense to replace this with:
>
> flags = console_srcu_read_flags(con);
>
> if (WARN_ON_ONCE(!(flags & CON_NBCON) ||
> !console_is_usable(con, flags, use_atomic, ctxt->allow_unsafe_takeover))) {
>
>
> Note that I have added the 4th parameter intentionally, see below.
...
> It would be more reliable when the check was integrated into
> console_is_usable(). I guess that you did not do it because
> it added another parameter...
Not all console_is_usable() call sites have a printing context. That is
why I only added the checks only to the actual ->write_atomic() paths
that were possible via nbcon_atomic_flush_unsafe().
> Or maybe, we could define @allow_unsafe_takeover via a global variable,
> e.g. panic_nbcon_allow_unsafe_takeover. And it might be valid
> only on the panic CPU, e.g.
>
> static inline
> bool nbcon_allow_unsafe_takeover(void)
> {
> return panic_on_this_cpu() && panic_nbcon_allow_unsafe_takeover;
> }
>
> It is a kind of hack. But it might be better than the 4th parameter.
> And it would simplify few other APIs.
After weighing the pros/cons I think that a global variable makes the
most sense. It will simplify internal APIs and provide all
console_is_usable() users a correct value. And the end result is no
different than what we do now.
We could also keep its setting inside nbcon_atomic_flush_unsafe() so
that the variable remains a printk-internal variable.
John
next prev parent reply other threads:[~2025-09-17 12:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 12:18 [PATCH printk v1 0/1] Allow unsafe ->write_atomic() for panic John Ogness
2025-09-12 12:18 ` [PATCH printk v1 1/1] printk: nbcon: Allow unsafe write_atomic() " John Ogness
2025-09-15 14:01 ` Breno Leitao
2025-09-15 14:14 ` John Ogness
2025-09-15 15:46 ` Breno Leitao
2025-09-15 19:09 ` John Ogness
2025-09-16 13:25 ` Petr Mladek
2025-09-16 15:05 ` Petr Mladek
2025-09-17 12:47 ` John Ogness [this message]
2025-09-17 13:51 ` Petr Mladek
2025-09-22 10:44 ` John Ogness
2025-09-22 11:45 ` Petr Mladek
2025-09-23 12:30 ` Breno Leitao
2025-09-17 14:44 ` [PATCH printk v1 0/1] Allow unsafe ->write_atomic() " Breno Leitao
2025-09-26 9:21 ` John Ogness
2025-09-26 15:17 ` Breno Leitao
2025-09-29 12:18 ` Petr Mladek
2025-09-29 13:36 ` John Ogness
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=848qidw8ip.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=efault@gmx.de \
--cc=gregkh@linuxfoundation.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.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.