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