Linux Serial subsystem development
 help / color / mirror / Atom feed
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

  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