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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z6XtgpGF-liq5I5z-jkeeping@inmusicbrands.com>
Date: Fri, 7 Feb 2025 11:24:50 +0000
From: John Keeping <jkeeping@...usicbrands.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.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 08:55:09PM +0200, Andy Shevchenko wrote:
> 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?

I'll add one in v2.

> > +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;

Will change in v2.

> > +		/*
> > +		 * 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);
> > +	}
> > +}

Thanks for the review!


Regards,
John