From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Samarth Narang <samarth.colleges@gmail.com>,
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
Subject: Re: [PATCH] tty: serial: samsung: use dmaengine_terminate_sync() in release_dma
Date: Sat, 31 Oct 2026 01:02:32 +0100 [thread overview]
Message-ID: <8cd8d4de-2174-4d64-9aa8-f65e47942904@samsung.com> (raw)
In-Reply-To: <20261030162334.3000737-1-samarth.colleges@gmail.com>
On 30.10.2026 17:23, Samarth Narang wrote:
> 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>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.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?
Yes, this need to be fixed.
> - s3c24xx_serial_stop_rx() calls dmaengine_pause(dma->tx_chan) before
> checking the RX channel's residue. Should this instead use
> dma->rx_chan?
Right, definitely that's a bug in current code.
>
> 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
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
prev parent reply other threads:[~2026-10-31 0:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261030162739eucas1p18c5a6e164b995c7e15adf4d989577e4c@eucas1p1.samsung.com>
2026-10-30 16:23 ` Samarth Narang
2026-10-31 0:02 ` Marek Szyprowski [this message]
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=8cd8d4de-2174-4d64-9aa8-f65e47942904@samsung.com \
--to=m.szyprowski@samsung.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 \
--cc=samarth.colleges@gmail.com \
/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
all inboxes | Powered by JetHome®