On Mon, 16 Oct 2023, Ilpo Järvinen wrote:
> On Mon, 16 Oct 2023, Richard Laing wrote:
>
> Your subject line is way too long. If you refer to some other issue,
> please link to it properly with commit id and/or with Link: tags.
>
> > Writes to UART_LCR can result in characters that are currently held in the
> > TX FIFO being lost rather than sent, even if the userspace process has
> > attempted to flush them.
> >
> > This is most visible when using the "resize" command (tested on Busybox),
> > where we have observed the escape code for restoring cursor position
> > becoming mangled.
> >
> > Since this appears to be a more common problem add a new driver option
> > to flush the TX FIFO before writing to the UART_LCR.
>
> This looks like a problem we already have solution for, the userspace can
> use TCSADRAIN/FLUSH to indicate what kind of flushing it wants for Tx
> when it makes the tcsetattr() call. Thus, userspace can avoid the Tx side
> corruption as long as its behavior is sane and doesn't e.g. try to race
> writes with tcsetattr() call as mentioned in commit 094fb49a2d0d ("tty:
> Prevent writing chars during tcsetattr TCSADRAIN/FLUSH").
I'm sorry, it was actually mentioned in commit 146a37e05d62 ("serial:
8250: Fix serial8250_tx_empty() race with DMA Tx") although that
094fb49a2d0d is also related to the draining.
> Have you tried to use the userspace solution? Isn't it working for some
> reason?
--
i.
