Re: [PATCH v2 2/2] serial: 8250_mid: wait for LSR tx empty before setting termios

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] `serial8250_wait_for_xmitr()` timeout is too short to drain the FIFO, failing to prevent data corruption.
- [High] `uart_port_unlock_irq()` unconditionally enables local interrupts, violating caller context expectations.
- [High] Releasing the port lock between Intel-specific register updates and core 8250 register updates introduces a TOCTOU race condition that corrupts transmission.
- [Low] Missing MODULE_IMPORT_NS("SERIAL_8250") causes a modpost namespace warning/error.
--

commit f345869677f080c82ebb31b7ea7f98c00bfefd55
Author: Tate Whiteberg <whiteberg@arista.com>

serial: 8250_mid: wait for LSR tx empty before setting termios

If mid8250_set_termios() is called while data is still in transmission,
the corresponding register updates will corrupt the transmission. This patch
locks the port and waits for the transmitter to empty before performing
the register updates.

> diff --git a/drivers/tty/serial/8250/8250_mid.c b/drivers/tty/serial/8250/8250_mid.c
> index 82656645b8a64..ce792888acfee 100644
> --- a/drivers/tty/serial/8250/8250_mid.c
> +++ b/drivers/tty/serial/8250/8250_mid.c

[ ... ]

> @@ -231,12 +232,18 @@ static void mid8250_set_termios(struct uart_port *p, struct ktermios *termios,
>  	}
>  
>  	rational_best_approximation(fuart, mid->board->freq, w, w, &mul, &div);
> +
> +	uart_port_lock_irq(p);

[Severity: High]
Does acquiring the port lock here using uart_port_lock_irq() break caller
context expectations?

Since mid8250_set_termios() serves as the set_termios callback, it is
frequently called from contexts where local interrupts are already disabled
(such as early boot console setup). 

This will eventually pair with uart_port_unlock_irq() below, which
unconditionally re-enables hardware interrupts via local_irq_enable(),
rather than restoring the previous interrupt state.

Should this use uart_port_lock_irqsave(p, &flags) instead?

> +
>  	p->uartclk = fuart * 16 / ps;		/* core uses ps = 16 always */
> +	serial8250_wait_for_xmitr(up, UART_LSR_BOTH_EMPTY);

[Severity: High]
Can this wait silently time out and fail to prevent data corruption?

The 8250_mid UART (PORT_16750) has a 64-byte FIFO. However, 
serial8250_wait_for_xmitr() internally calls wait_for_lsr(), which uses a
timeout of up->port.frame_time * 2 (approximately 2 characters).

If there is a large burst in the FIFO at a low baud rate, won't this wait
time out long before the 64-byte FIFO drains, proceeding to modify the
PS/MUL/DIV registers while data is still actively shifting out?


[Severity: Low]
Does this module need to import the SERIAL_8250 namespace?

The function serial8250_wait_for_xmitr() is exported to the "SERIAL_8250"
namespace in drivers/tty/serial/8250/8250_port.c. Since 8250_mid.c is
compiled as a separate module (8250_mid.ko), failing to include
MODULE_IMPORT_NS("SERIAL_8250") at the module definition level will trigger
a modpost namespace warning or error when building the driver as a module.

>  
>  	writel(ps, p->membase + INTEL_MID_UART_PS);		/* set PS */
>  	writel(mul, p->membase + INTEL_MID_UART_MUL);		/* set MUL */
>  	writel(div, p->membase + INTEL_MID_UART_DIV);
>  
> +	uart_port_unlock_irq(p);
> +
>  	serial8250_do_set_termios(p, termios, old);

[Severity: High]
Does releasing the port lock here introduce a race condition?

The lock is dropped before calling serial8250_do_set_termios(), which then
re-acquires the lock to update DLL/DLM and LCR.

During this unlocked window, the port is left in an inconsistent hardware
state with new clock multipliers but the old divisor. 

Because interrupts are enabled, could a TX interrupt or concurrent console
write acquire the lock, fill the hardware FIFO with new data, and transmit
it at a garbled frequency before the core 8250 function completes the update?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828175733.1650267-1-whiteberg@arista.com?part=2