linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Ilpo Järvinen'" <ilpo.jarvinen@linux.intel.com>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v2 2/2] serial: 8250: Fix serial8250_tx_empty() race with DMA Tx
Date: Sat, 18 Mar 2023 11:47:15 +0000	[thread overview]
Message-ID: <52fae6e3e7254a96beefd2774f7d6254@AcuMS.aculab.com> (raw)
In-Reply-To: <20230317113318.31327-3-ilpo.jarvinen@linux.intel.com>

From: Ilpo Järvinen
> Sent: 17 March 2023 11:33
> To: linux-serial@vger.kernel.org; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Jiri Slaby
> 
> There's a potential race before THRE/TEMT deasserts when DMA Tx is
> starting up (or the next batch of continuous Tx is being submitted).
> This can lead to misdetecting Tx empty condition.
> 
> It is entirely normal for THRE/TEMT to be set for some time after the
> DMA Tx had been setup in serial8250_tx_dma(). As Tx side is definitely
> not empty at that point, it seems incorrect for serial8250_tx_empty()
> claim Tx is empty.
> 
> Fix the race by also checking in serial8250_tx_empty() whether there's
> DMA Tx active.
> 
> Note: This fix only addresses in-kernel race mainly to make using
> TCSADRAIN/FLUSH robust. Userspace can still cause other races but they
> seem userspace concurrency control problems.

Looks better, but I'm not sure it actually works.

If interrupts are being used to copy data to the tx fifo then
(depending on interrupt latency and exactly when the interrupt
is requested) the code might report 'tx empty' when the ISR
is about to copy in more data.

Now the drain/flush code might already have checked there is
no more data queued in the driver before calling this,
but more generally shouldn't it be checking:
	no_data_queued_in_driver && hardware_fifo_empty.

Any 'no_data_queued_in_driver' check would probably include
data that dma is copying - so the explicit dma check might
not be needed.

	David

> 
> Fixes: 9ee4b83e51f74 ("serial: 8250: Add support for dmaengine")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
>  drivers/tty/serial/8250/8250.h      | 12 ++++++++++++
>  drivers/tty/serial/8250/8250_port.c |  7 ++++---
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
> index 287153d32536..1e8fe44a7099 100644
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -365,6 +365,13 @@ static inline void serial8250_do_prepare_rx_dma(struct uart_8250_port *p)
>  	if (dma->prepare_rx_dma)
>  		dma->prepare_rx_dma(p);
>  }
> +
> +static inline bool serial8250_tx_dma_running(struct uart_8250_port *p)
> +{
> +	struct uart_8250_dma *dma = p->dma;
> +
> +	return dma && dma->tx_running;
> +}
>  #else
>  static inline int serial8250_tx_dma(struct uart_8250_port *p)
>  {
> @@ -380,6 +387,11 @@ static inline int serial8250_request_dma(struct uart_8250_port *p)
>  	return -1;
>  }
>  static inline void serial8250_release_dma(struct uart_8250_port *p) { }
> +
> +static inline bool serial8250_tx_dma_running(struct uart_8250_port *p)
> +{
> +	return false;
> +}
>  #endif
> 
>  static inline int ns16550a_goto_highspeed(struct uart_8250_port *up)
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index fa43df05342b..107bcdfb119c 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2005,18 +2005,19 @@ static int serial8250_tx_threshold_handle_irq(struct uart_port *port)
>  static unsigned int serial8250_tx_empty(struct uart_port *port)
>  {
>  	struct uart_8250_port *up = up_to_u8250p(port);
> +	unsigned int result = 0;
>  	unsigned long flags;
> -	u16 lsr;
> 
>  	serial8250_rpm_get(up);
> 
>  	spin_lock_irqsave(&port->lock, flags);
> -	lsr = serial_lsr_in(up);
> +	if (!serial8250_tx_dma_running(up) && uart_lsr_tx_empty(serial_lsr_in(up)))
> +		result = TIOCSER_TEMT;
>  	spin_unlock_irqrestore(&port->lock, flags);
> 
>  	serial8250_rpm_put(up);
> 
> -	return uart_lsr_tx_empty(lsr) ? TIOCSER_TEMT : 0;
> +	return result;
>  }
> 
>  unsigned int serial8250_do_get_mctrl(struct uart_port *port)
> --
> 2.30.2

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2023-03-18 11:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 11:33 [PATCH v2 0/2] tty/serial: Fix tcsetattr() TCSADRAIN/FLUSH and write() races Ilpo Järvinen
2023-03-17 11:33 ` [PATCH v2 1/2] tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH Ilpo Järvinen
2023-03-17 11:33 ` [PATCH v2 2/2] serial: 8250: Fix serial8250_tx_empty() race with DMA Tx Ilpo Järvinen
2023-03-18 11:47   ` David Laight [this message]
2023-03-20  9:00     ` Ilpo Järvinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52fae6e3e7254a96beefd2774f7d6254@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).