mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


      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®