Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Samarth Narang <samarth.colleges@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Peter Griffin <peter.griffin@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>,
	linux-samsung-soc@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Samarth Narang <samarth.colleges@gmail.com>
Subject: [PATCH] tty: serial: samsung: use dmaengine_terminate_sync() in release_dma
Date: Fri, 30 Oct 2026 16:23:34 +0000	[thread overview]
Message-ID: <20261030162334.3000737-1-samarth.colleges@gmail.com> (raw)

s3c24xx_serial_release_dma() stops the RX and TX DMA channels using the
deprecated dmaengine_terminate_all() before unmapping their buffers and
freeing the RX buffer. Since this does not guarantee that DMA transfers
or their completion callbacks have finished, the controller may continue
accessing memory after it has been unmapped or returned to the
allocator, particularly when the port is shut down while RX DMA is
active.

Replace dmaengine_terminate_all() with dmaengine_terminate_sync() to
ensure that outstanding DMA activity is terminated before the buffers
are released. Both callers of s3c24xx_serial_release_dma() run in
process context, where synchronous termination is permitted.

Fixes: 62c37eedb74c ("serial: samsung: add dma reqest/release functions")
Assisted-by: LLM
Signed-off-by: Samarth Narang <samarth.colleges@gmail.com>
---
This issue was identified by a research static analyzer for DMA
lifecycle ordering and has not been validated on hardware. The patch has
only been compile-tested on arm64 with W=1.

On Exynos systems, the UART uses PL330, which does not implement a
device_synchronize callback, so this change follows the DMAengine API
contract without independently establishing that all hardware activity
has stopped. The PL330 termination behavior is being raised separately
with the DMAengine maintainers.

Two related questions outside the scope of this patch:

- s3c24xx_serial_rx_dma_complete() unconditionally re-arms RX DMA,
  potentially racing with release_dma() and submitting another
  descriptor after termination. Should shutdown prevent further
  submissions before terminating the channel?
- s3c24xx_serial_stop_rx() calls dmaengine_pause(dma->tx_chan) before
  checking the RX channel's residue. Should this instead use
  dma->rx_chan?

 drivers/tty/serial/samsung_tty.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 640f85e2d..4eeef149b 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -1145,7 +1145,7 @@ static void s3c24xx_serial_release_dma(struct s3c24xx_uart_port *p)
 	struct s3c24xx_uart_dma	*dma = p->dma;
 
 	if (dma->rx_chan) {
-		dmaengine_terminate_all(dma->rx_chan);
+		dmaengine_terminate_sync(dma->rx_chan);
 		dma_unmap_single(dmaengine_get_dma_device(dma->rx_chan), dma->rx_addr,
 				 dma->rx_size, DMA_FROM_DEVICE);
 		kfree(dma->rx_buf);
@@ -1154,7 +1154,7 @@ static void s3c24xx_serial_release_dma(struct s3c24xx_uart_port *p)
 	}
 
 	if (dma->tx_chan) {
-		dmaengine_terminate_all(dma->tx_chan);
+		dmaengine_terminate_sync(dma->tx_chan);
 		dma_unmap_single(dmaengine_get_dma_device(dma->tx_chan), dma->tx_addr,
 				 UART_XMIT_SIZE, DMA_TO_DEVICE);
 		dma_release_channel(dma->tx_chan);

base-commit: 83f32c773255720a661aa45d83e36278135f23f5


                 reply	other threads:[~2026-10-30 16:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261030162334.3000737-1-samarth.colleges@gmail.com \
    --to=samarth.colleges@gmail.com \
    --cc=alim.akhtar@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter.griffin@linaro.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