Re: [PATCH 0/2] braille: nbcon: Allow using a serial driver converted to nbcon API as a Braille console

[Petr Mladek <pmladek@suse.com>]

On Fri 2026-09-25 15:14:16, John Ogness wrote:
> On 2026-09-22, Petr Mladek <pmladek@suse.com> wrote:
> > I have been working on v5 [1] of the patchset cleaning console registration
> > code and I found that the system did not boot when I selected a Braille
> > on the command line, for example:
> >
> >      console=brl,ttyS0,115200 console=tty0
> >
> > Bisection went down to the commit d3539347022a ("serial: 8250: Switch to
> > nbcon console, take 2"). I found that the Braille console driver called
> > braille_co->write() internally where braille_co pointed to the uart
> > 8250 driver.
> 
> The Braille console blindly calling (struct console).write() is
> obviously bad. This needs to be fixed. And not just because of the
> 8250. Other NBCON drivers already exist mainline and have this same
> issue.
> 
> > I added the support for the nbcon console API similar way as we did
> > for kdb [2].
> 
> kdb does not need to care about latencies. The Braille consoles do. I
> will comment more on this in the related patch.
> 
> > Note 1: I believe that we have a bug in the kdb patch because we call
> >         con->write() atomic callback after entering the unsafe mode.
> >         But we should do so in the default "safe" mode.
> 
> Why do you believe this? kdb operates within an unsafe section so that
> other CPUs cannot take ownership. (BTW: For kdb the other CPUs are
> supposed to be quiesced, so there should not be any ownership attempts
> anyway. The unsafe section is just an extra precaution.)

It is safe from the kdb context POV. But it is not right from the API
POV. The API does not suport nested unsafe section, so the following
happens:

  kdb_msg_write()

	nbcon_kdb_try_acquire(c, &wctxt);
	// on success: nbcon acquired, entered unsafe context
	c->write_atomic(c, &wctxt);

		serial8250_console_write()
			nbcon_enter_unsafe()
			// nested unsafe context
			nbcon_exit_unsafe(wctxt);
			// the nbcon context is marked as safe
			return;

	// the nbcon context is marked as save even though
	// kdb_msg_write() did not call nbcon_exit_unsafe()
	// which might lead to bugs

As you say, it is not a real problem here in the kdb code
because other CPUs are stopped. But it is an error prone pattern.
IMHO, we have already talked about adding warnings to catch nested
nbcon_enter_unsafe()/nbcon_exit_unsafe() calls.


> > Note 2: I am not completely sure about the locking. It might be better
> >         to use NBCON_PRIO_PANIC in panic().
> 
> Why does it matter? printk() is not trying to do any Braille printing
> during panic, so it will not attempt to acquire the Braille console.

The Braille console show exactly what the graphical console show.
It shows printk() messages when ttyX is registered as a console.

> >       Also I thought about using con->write_thread(). But I think
> > 	that we have to use the atomic variant because the Braille
> > 	console can be called from printk() via the VT code, aka
> > 	graphical console.
> 
> How can it be called from printk()? Even printk() writing to VT is only
> if it is registered as a console. Braille consoles are not registered.
> Please explain.

I have added WARN_ON() into braille_write() and got this:

[    0.069344] WARNING: drivers/accessibility/braille/braille_console.c:115 at braille_write+0x231/0x300, CPU#0: swapper/0/0
[    0.069352] Modules linked in:
[    0.069355] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5-default+ #139 PREEMPT(full)  db5f4527e6a3b5c4863452c3023f648284afb38d
[    0.069358] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-2-g4f253b9b-prebuilt.qemu.org 04/01/2014
[    0.069359] RIP: 0010:braille_write+0x231/0x300
[    0.069362] Code: 71 02 41 83 c8 40 44 88 06 48 8d 56 02 c6 46 01 02 41 f6 42 49 01 0f 84 98 00 00 00 49 83 ba 80 00 00 00 00 0f 84 b0 00 00 00 <0f> 0b 48 8d 74 24 5a 48 8d 7c 24 08 29 f2
 e8 2c d2 08 ff 48 8b 3d
[    0.069363] RSP: 0000:ffffffffaf603b78 EFLAGS: 00010086
[    0.069365] RAX: ffffffffb15c2e70 RBX: ffffffffb15c2e20 RCX: ffffffffaf603bfb
[    0.069366] RDX: ffffffffaf603bfe RSI: ffffffffaf603bfc RDI: 0000000000000020
[    0.069367] RBP: 00000000ffffffff R08: 0000000000000045 R09: ffffffffb15c2e70
[    0.069367] R10: ffffffffaf9f5a20 R11: 0000000000000000 R12: 0000000000000000
[    0.069368] R13: 0000000000000003 R14: ffffffffaf603ce8 R15: ffffffffafa33930
[    0.069371] FS:  0000000000000000(0000) GS:ffff8d04287a1000(0000) knlGS:0000000000000000
[    0.069372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.069373] CR2: ffff8d03fffff000 CR3: 000000000b656000 CR4: 00000000000100b0
[    0.069376] Call Trace:
[    0.069377]  <TASK>
[    0.069378]  ? check_prev_add+0xf2/0xe40
[    0.069392]  ? lock_acquire.part.0+0xc5/0x230
[    0.069394]  ? atomic_notifier_call_chain+0x2a/0x110
[    0.069398]  vt_notifier_call+0x183/0x380
[    0.069402]  ? rcu_is_watching+0x11/0x50
[    0.069405]  ? __pfx_vt_notifier_call+0x10/0x10
[    0.069406]  notifier_call_chain+0x5d/0x170
[    0.069413]  atomic_notifier_call_chain+0x5f/0x110
[    0.069417]  vt_console_print+0x22e/0x4c0
[    0.069424]  ? console_emit_next_record+0x23a/0x2c0
[    0.069428]  console_emit_next_record+0x264/0x2c0
[    0.069430]  ? console_emit_next_record+0x23a/0x2c0
[    0.069439]  console_flush_one_record+0x210/0x340
[    0.069446]  console_unlock+0x6f/0x130
[    0.069447]  ? vprintk_emit+0x187/0x250
[    0.069451]  vprintk_emit+0x1fe/0x250
[    0.069457]  _printk+0x5b/0x80
[    0.069463]  ? __pfx_univ8250_console_init+0x10/0x10
[    0.069470]  lockdep_init+0x10/0xc0
[    0.069474]  start_kernel+0x5f2/0x720
[    0.069481]  x86_64_start_reservations+0x24/0x30
[    0.069484]  x86_64_start_kernel+0xd5/0xe0
[    0.069487]  common_startup_64+0x13e/0x151
[    0.069501]  </TASK>
[    0.069502] irq event stamp: 324
[    0.069502] hardirqs last  enabled at (323): [<ffffffffad43d623>] __down_trylock_console_sem+0x93/0xa0
[    0.069506] hardirqs last disabled at (324): [<ffffffffad44072e>] console_emit_next_record+0x21e/0x2c0
[    0.069507] softirqs last  enabled at (0): [<0000000000000000>] 0x0
[    0.069510] softirqs last disabled at (0): [<0000000000000000>] 0x0
[    0.069511] ---[ end trace 0000000000000000 ]---

This shows that braille_write() is called form printk() even when
braille_co is not in console_list. It is called via vt_console_print()
because the graphical console driver (ttyX) is registered.

Best Regards,
Petr