Re: [PATCH v6 5/9] serial: max310x: wait for TX to drain before powering down in shutdown

[Tapio Reijonen <tapio.reijonen@vaisala.com>]

On 10/4/26 15:28, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Can this loop be used to cause a local Denial of Service via an
> extended D-state hang or Hung Task Panic?
>
> If a user opens the TTY, configures a very low baud rate (e.g.,
> speed 1-50), disables CTS flow control (preventing the TX FIFO from
> draining), and closes the device, max310x_shutdown() could call
> fsleep() up to 129 times in TASK_UNINTERRUPTIBLE.

Agreed, the loop waits on data, so a blocked FIFO makes close() pay
for it. One precision note: the baud rate generator floors at
uartclk / 16 / 0xffff, tens of baud with the usual crystals, so the
1-baud / 20-minute case is not reachable - but ~26 s per close() at
50 baud with CTS blocked is real and bad enough.

v7 will rework shutdown() to stop the transmitter instead of
draining it, following what imx.c does: set MODE1 TxDisabl (the
character in flight completes, the rest of the FIFO is abandoned -
the next startup() resets the FIFOs anyway) and honour only the RTS
timing. On the auto-RTS path the FIFO is also reset, so the engine
sees the transmitter empty and releases RTS before the power-off
freezes the pin. The wait is then bounded by one character plus the
configured after-send delay, independent of how much data was
queued: measured on a MAX14830 board, a close() with a second of
data still in flight at 50 baud takes 0.23 s instead of 2.4, and the
CTS-blocked case no longer waits on data at all. Data the tty layer
explicitly did not wait for is then truncated rather than drained,
which matches how other RS485 drivers close.

Tapio