From: John Ogness <john.ogness@linutronix.de>
To: Marcos Paulo de Souza <mpdesouza@suse.com>,
Petr Mladek <pmladek@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Jason Wessel <jason.wessel@windriver.com>,
Daniel Thompson <danielt@kernel.org>,
Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org,
kgdb-bugreport@lists.sourceforge.net
Subject: Re: [PATCH v3 4/4] kdb: Adapt kdb_msg_write to work with NBCON consoles
Date: Tue, 09 Sep 2025 10:03:05 +0206 [thread overview]
Message-ID: <84segwjbxq.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <d73e8cc0259c140a0a49f670c6c165bb662281ed.camel@suse.com>
On 2025-09-08, Marcos Paulo de Souza <mpdesouza@suse.com> wrote:
>> > --- a/kernel/debug/kdb/kdb_io.c
>> > +++ b/kernel/debug/kdb/kdb_io.c
>> > @@ -589,24 +589,40 @@ static void kdb_msg_write(const char *msg,
>> > int msg_len)
>> > */
>> > cookie = console_srcu_read_lock();
>> > for_each_console_srcu(c) {
>> > - if (!(console_srcu_read_flags(c) & CON_ENABLED))
>> > + struct nbcon_write_context wctxt = { };
>> > + short flags = console_srcu_read_flags(c);
>> > +
>> > + if (!console_is_usable(c, flags, true))
>> > continue;
>> > if (c == dbg_io_ops->cons)
>> > continue;
>> > - if (!c->write)
>> > - continue;
>> > - /*
>> > - * Set oops_in_progress to encourage the console
>> > drivers to
>> > - * disregard their internal spin locks: in the
>> > current calling
>> > - * context the risk of deadlock is a bigger
>> > problem than risks
>> > - * due to re-entering the console driver. We
>> > operate directly on
>> > - * oops_in_progress rather than using
>> > bust_spinlocks() because
>> > - * the calls bust_spinlocks() makes on exit are
>> > not appropriate
>> > - * for this calling context.
>> > - */
>> > - ++oops_in_progress;
>> > - c->write(c, msg, msg_len);
>> > - --oops_in_progress;
>> > +
>> > + if (flags & CON_NBCON) {
>> > + /*
>> > + * Do not continue if the console is NBCON
>> > and the context
>> > + * can't be acquired.
>> > + */
>> > + if (!nbcon_kdb_try_acquire(c, &wctxt))
>> > + continue;
>> > +
>> > + wctxt.outbuf = (char *)msg;
>> > + wctxt.len = msg_len;
>>
>> I double checked whether we initialized all members of the structure
>> correctly. And I found that we didn't. We should call here:
>>
>> nbcon_write_context_set_buf(&wctxt,
>> &pmsg.pbufs-
>> >outbuf[0],
>>
>> pmsg.outbuf_len);
Nice catch.
>> Sigh, this is easy to miss. I remember that I was not super happy
>> about this design. But the original code initialized the structure
>> on a single place...
>
> Ok, so I'll need to also export nbcon_write_context_set_buf, since it's
> currently static inside kernel/printk/nbcon.c. I'll do it for the next
> version.
How about modifying nbcon_kdb_try_acquire() to also take @msg and
@msg_len. Then, on success, @wctxt is already prepared. I do not like
the idea of external code fiddling with the fields.
John
next prev parent reply other threads:[~2025-09-09 7:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 18:33 [PATCH v3 0/4] Handle NBCON consoles on KDB Marcos Paulo de Souza
2025-09-02 18:33 ` [PATCH v3 1/4] printk: nbcon: Export console_is_usable Marcos Paulo de Souza
2025-09-05 13:48 ` Petr Mladek
2025-09-02 18:33 ` [PATCH v3 2/4] printk: nbcon: Introduce KDB helpers Marcos Paulo de Souza
2025-09-05 16:21 ` Petr Mladek
2025-09-08 12:09 ` John Ogness
2025-09-09 14:21 ` Petr Mladek
2025-09-09 14:38 ` John Ogness
2025-09-02 18:33 ` [PATCH v3 3/4] printk: nbcon: Allow KDB to acquire the NBCON context Marcos Paulo de Souza
2025-09-05 14:52 ` John Ogness
2025-09-05 18:30 ` Marcos Paulo de Souza
2025-09-08 15:23 ` Petr Mladek
2025-09-09 7:53 ` John Ogness
2025-09-08 15:14 ` Petr Mladek
2025-09-02 18:33 ` [PATCH v3 4/4] kdb: Adapt kdb_msg_write to work with NBCON consoles Marcos Paulo de Souza
2025-09-08 15:51 ` Petr Mladek
2025-09-08 19:27 ` Marcos Paulo de Souza
2025-09-09 7:57 ` John Ogness [this message]
2025-09-09 11:39 ` Marcos Paulo de Souza
2025-09-09 13:48 ` Petr Mladek
2025-09-09 14:23 ` John Ogness
2025-09-09 15:03 ` 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=84segwjbxq.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=danielt@kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jason.wessel@windriver.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpdesouza@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox