From: sashiko-bot@kernel.org
To: "Petr Mladek" <pmladek@suse.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH v4 1/1] braille: nbcon: Allow to use a serial console with NBCON API as Braille console
Date: Thu, 01 Oct 2026 14:24:07 +0000 [thread overview]
Message-ID: <20261001142407.84C721F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001140727.124398-2-pmladek@suse.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] console: deadlock in braille_write() from atomic/IRQ context
- [High] console: infinite loop in braille_write() when CONFIG_PRINTK is disabled
--
commit 0bb1344e643dce4e38416fdf04095c16fe6023c8
Author: Petr Mladek <pmladek@suse.com>
braille: nbcon: Allow to use a serial console with NBCON API as Braille console
This patch integrates the Braille console with the NBCON API by allowing
braille_write() to attempt acquiring NBCON ownership before writing. It
simulates the original locking using nbcon_braille_try_acquire() and routes
output through write_atomic() or write_thread() callbacks.
> diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
> --- a/drivers/accessibility/braille/braille_console.c
> +++ b/drivers/accessibility/braille/braille_console.c
[ ... ]
> @@ -62,14 +62,50 @@ static void braille_write(u16 *buf)
[ ... ]
> + if (braille_co->flags & CON_NBCON) {
> + if (panic_on_this_cpu()) {
> + /*
> + * This should be good enough in practice. Most/all
> + * serial console drivers have the atomic callback.
> + */
> + if (!braille_co->write_atomic)
> + return;
> +
> + local_irq_save(flags);
> + /* NBCON API strictly requires the ownership. */
> + if (!nbcon_braille_try_acquire(braille_co, &wctxt)) {
> + local_irq_restore(flags);
> + return;
> + }
> + } else {
> + braille_co->device_lock(braille_co, &flags);
> + while (!nbcon_braille_try_acquire(braille_co, &wctxt))
> + cpu_relax();
> + }
> + }
[Severity: High]
Could this lead to a deadlock? braille_write() can be invoked by VT
notifiers from atomic or IRQ contexts (e.g., from keyboard interrupts or
console_flush_all()). By calling device_lock() and spinning on NBCON
ownership with a cpu_relax() loop, if the interrupted context already holds
the lock (like an active nbcon flush), nbcon_braille_try_acquire() will
permanently return false, causing an infinite busy-loop.
[ ... ]
> @@ -102,7 +138,24 @@ static void braille_write(u16 *buf)
[ ... ]
> - braille_co->write(braille_co, data, c - data);
> + if (braille_co->flags & CON_NBCON) {
> + nbcon_write_context_set_buf(&wctxt, (char *)data, c - data);
> + if (panic_on_this_cpu())
> + braille_co->write_atomic(braille_co, &wctxt);
> + else
> + braille_co->write_thread(braille_co, &wctxt);
[Severity: High]
Does this violate the write_thread API constraints? The
include/linux/console.h documentation specifies that write_thread must
strictly execute in a task context. Since braille_write() can be called
from an atomic or IRQ context, invoking the kthread-specific callback here
could be unsafe.
> + } else {
> + braille_co->write(braille_co, data, c - data);
> + }
[ ... ]
> diff --git a/include/linux/console.h b/include/linux/console.h
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
[ ... ]
> @@ -678,8 +687,14 @@ static inline void nbcon_reacquire_nobuf(struct nbcon_write_context *wctxt) { }
> static inline bool nbcon_kdb_try_acquire(struct console *con,
> struct nbcon_write_context *wctxt) { return false; }
> static inline void nbcon_kdb_release(struct nbcon_write_context *wctxt) { }
> +static inline
> +bool nbcon_write_context_is_braille(struct nbcon_write_context *wctxt) { return false; }
> static inline bool console_is_usable(struct console *con, short flags,
> bool use_atomic) { return false; }
> +static inline bool nbcon_braille_try_acquire(struct console *con,
> + struct nbcon_write_context *wctxt) { return false; }
[Severity: High]
Could this cause a hard lockup if CONFIG_A11Y_BRAILLE_CONSOLE is enabled
but CONFIG_PRINTK is disabled?
Since this fallback stub unconditionally returns false, the
while (!nbcon_braille_try_acquire(...)) cpu_relax(); loop in braille_write()
will never terminate when triggered by terminal output.
> +static inline void nbcon_braille_release(struct nbcon_write_context *wctxt) { }
> +static inline bool nbcon_is_braille(struct console *con) { return false; }
> #endif
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261001140727.124398-1-pmladek@suse.com?part=1
next prev parent reply other threads:[~2026-10-01 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 14:07 [PATCH v4 0/1] braille: nbcon: Fix Braille console for NBCON API Petr Mladek
2026-10-01 14:07 ` [PATCH v4 1/1] braille: nbcon: Allow to use a serial console with NBCON API as Braille console Petr Mladek
2026-10-01 14:24 ` sashiko-bot [this message]
2026-10-02 8:14 ` Petr Mladek
2026-10-01 15:32 ` John Ogness
2026-10-02 8:50 ` Petr Mladek
2026-10-02 9:13 ` 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=20261001142407.84C721F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
/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