linux-kernel - Re: [PATCH] serial: 8250: Fix fifo underflow on flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z6UFjU9SM4laZRyW@smile.fi.intel.com>
Date: Thu, 6 Feb 2025 20:55:09 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: John Keeping <jkeeping@...usicbrands.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>, Matt Turner <mattst88@...il.com>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	John Ogness <john.ogness@...utronix.de>,
	Arnd Bergmann <arnd@...db.de>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Ferry Toth <ftoth@...londelft.nl>, Petr Mladek <pmladek@...e.com>,
	Niklas Schnelle <schnelle@...ux.ibm.com>,
	Serge Semin <fancer.lancer@...il.com>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: Fix fifo underflow on flush

On Thu, Feb 06, 2025 at 03:55:51PM +0000, John Keeping wrote:
> When flushing the serial port's buffer, uart_flush_buffer() calls
> kfifo_reset() but if there is an outstanding DMA transfer then the
> completion function will consume data from the kfifo via
> uart_xmit_advance(), underflowing and leading to ongoing DMA as the
> driver tries to transmit another 2^32 bytes.
> 
> This is readily reproduced with serial-generic and amidi sending even
> short messages as closing the device on exit will wait for the fifo to
> drain and in the underflow case amidi hangs for 30 seconds on exit in
> tty_wait_until_sent().

Sounds not good user experience...

> A trace of that gives:
> 
>      kworker/1:1-84    [001]    51.769423: bprint:               serial8250_tx_dma: tx_size=3 fifo_len=3
>            amidi-763   [001]    51.769460: bprint:               uart_flush_buffer: resetting fifo
>  irq/21-fe530000-76    [000]    51.769474: bprint:               __dma_tx_complete: tx_size=3
>  irq/21-fe530000-76    [000]    51.769479: bprint:               serial8250_tx_dma: tx_size=4096 fifo_len=4294967293
>  irq/21-fe530000-76    [000]    51.781295: bprint:               __dma_tx_complete: tx_size=4096
>  irq/21-fe530000-76    [000]    51.781301: bprint:               serial8250_tx_dma: tx_size=4096 fifo_len=4294963197
>  irq/21-fe530000-76    [000]    51.793131: bprint:               __dma_tx_complete: tx_size=4096
>  irq/21-fe530000-76    [000]    51.793135: bprint:               serial8250_tx_dma: tx_size=4096 fifo_len=4294959101
>  irq/21-fe530000-76    [000]    51.804949: bprint:               __dma_tx_complete: tx_size=4096
> 
> Since the port lock is held in when the kfifo is reset in
> uart_flush_buffer() and in __dma_tx_complete(), adding a flush_buffer
> hook to adjust the outstanding DMA byte count is sufficient to avoid the
> kfifo underflow.

Shouldn't this have a Fixes tag?

...

> +void serial8250_tx_dma_flush(struct uart_8250_port *p)
> +{
> +	struct uart_8250_dma *dma = p->dma;

> +	if (dma->tx_running) {

	if (!dma->tx_running)
		return;

> +		/*
> +		 * kfifo_reset() has been called by the serial core, avoid
> +		 * advancing and underflowing in __dma_tx_complete().
> +		 */
> +		dma->tx_size = 0;
> +
> +		dmaengine_terminate_async(dma->rxchan);
> +	}
> +}

-- 
With Best Regards,
Andy Shevchenko