summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorIlpo Järvinen <ilpo.jarvinen@linux.intel.com>2022-06-15 12:06:49 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-06-27 14:47:57 +0200
commitf8d6e9d3ca5c68e24dd485132a93d49abd444eaf (patch)
treeab9539c618d9e220a6aba18ea876765d0d74da38 /include
parent211565b100993c90b53bf40851eacaefc830cfe0 (diff)
downloadlinux-stable-f8d6e9d3ca5c68e24dd485132a93d49abd444eaf.tar.gz
linux-stable-f8d6e9d3ca5c68e24dd485132a93d49abd444eaf.tar.bz2
linux-stable-f8d6e9d3ca5c68e24dd485132a93d49abd444eaf.zip
serial: 8250: Fix __stop_tx() & DMA Tx restart races
Commit e8ffbb71f783 ("serial: 8250: use THRE & __stop_tx also with DMA") changed __dma_tx_complete() to enable THRI that is cleared in __stop_tx() once THRE is asserted as UART runs out bits to transmit. It is possible, however, that more data arrives in between in which case serial8250_tx_dma() resumes Tx. THRI is not supposed to be on during DMA Tx because DMA is based on completion handler, therefore THRI must be cleared unconditionally in serial8250_tx_dma(). When Tx is about to start, another race window exists with serial8250_handle_irq() leading to a call into __stop_tx() while the Tx has already been resumed: __tx_complete(): -> spin_lock(port->lock) -> dma->tx_running = 0 -> serial8250_set_THRI() -> spin_unlock(port->lock) uart_start(): serial8250_handle_irq(): -> spin_lock(port->lock) -> serial8250_tx_dma(): -> dma->tx_running = 1 -> spin_unlock(port->lock) -> spin_lock(port->lock) -> __stop_tx() Close this race by checking !dma->tx_running before calling into __stop_tx(). Fixes: e8ffbb71f783 ("serial: 8250: use THRE & __stop_tx also with DMA") Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220615090651.15340-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions