[PATCH 0/3] dmaengine: Use non-atomic bit ops where safe

[PATCH 0/3] dmaengine: Use non-atomic bit ops where safe

[Peng Fan (OSS)]

dma_cap_set()/dma_cap_clear() and imx-sdma event_mask setup use atomic
set_bit()/clear_bit() in contexts where no concurrent access is
possible:

- dma_cap_set()/dma_cap_clear() are called exclusively during driver
  probe, before dma_async_device_register() makes the device visible.
- imx-sdma event_mask[] is zeroed and configured during channel setup
  while the channel is disabled.

Switch both to non-atomic __set_bit()/__clear_bit() equivalents.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
      dmaengine: Use non-atomic bit ops for cap_mask manipulation
      dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup
      dmaengine: imx-sdma: Use __assign_bit() for ownership configuration

 drivers/dma/imx-sdma.c    | 21 +++++----------------
 include/linux/dmaengine.h |  4 ++--
 2 files changed, 7 insertions(+), 18 deletions(-)
---
base-commit: 89c07d98716a13454ec3fd9f97689e812cc71bd4
change-id: 20260903-dma-mask-ddf64d770f7d

Best regards,
--  
Peng Fan <peng.fan@nxp.com>

[PATCH 1/3] dmaengine: Use non-atomic bit ops for cap_mask manipulation

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

dma_cap_set() and dma_cap_clear() are called exclusively during driver
probe, before dma_async_device_register() makes the device visible to
the rest of the system. There is no concurrent access to cap_mask at
that point, so switch to the non-atomic __set_bit()/__clear_bit()
equivalents.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 include/linux/dmaengine.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index fe33a20abc614..923d914691d06 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1551,14 +1551,14 @@ static inline bool async_tx_test_ack(struct dma_async_tx_descriptor *tx)
 static inline void
 __dma_cap_set(enum dma_transaction_type tx_type, dma_cap_mask_t *dstp)
 {
-	set_bit(tx_type, dstp->bits);
+	__set_bit(tx_type, dstp->bits);
 }
 
 #define dma_cap_clear(tx, mask) __dma_cap_clear((tx), &(mask))
 static inline void
 __dma_cap_clear(enum dma_transaction_type tx_type, dma_cap_mask_t *dstp)
 {
-	clear_bit(tx_type, dstp->bits);
+	__clear_bit(tx_type, dstp->bits);
 }
 
 #define dma_cap_zero(mask) __dma_cap_zero(&(mask))

-- 
2.34.1

[PATCH 2/3] dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

In sdma_set_watermarklevel_for_p2p(), the event_mask[] fields are zeroed
in sdma_config_channel() right before this function is called, and the
channel has already been disabled. There is no concurrent access to
event_mask at this point, so replace set_bit() with __set_bit().

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/dma/imx-sdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 36368835a845c..63261ab6402b9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1241,8 +1241,8 @@ static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 	int lwml = sdmac->watermark_level & SDMA_WATERMARK_LEVEL_LWML;
 	int hwml = (sdmac->watermark_level & SDMA_WATERMARK_LEVEL_HWML) >> 16;
 
-	set_bit(sdmac->event_id0 % 32, &sdmac->event_mask[1]);
-	set_bit(sdmac->event_id1 % 32, &sdmac->event_mask[0]);
+	__set_bit(sdmac->event_id0 % 32, &sdmac->event_mask[1]);
+	__set_bit(sdmac->event_id1 % 32, &sdmac->event_mask[0]);
 
 	if (sdmac->event_id0 > 31)
 		sdmac->watermark_level |= SDMA_WATERMARK_LEVEL_LWE;

-- 
2.34.1

[PATCH 3/3] dmaengine: imx-sdma: Use __assign_bit() for ownership configuration

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Replace the if/else pairs of __set_bit()/__clear_bit() in
sdma_config_ownership() with __assign_bit(), which does exactly the
same conditional set-or-clear in a single call.

No functional change.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/dma/imx-sdma.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 63261ab6402b9..da565409beaaa 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -710,20 +710,9 @@ static int sdma_config_ownership(struct sdma_channel *sdmac,
 	mcu = readl_relaxed(sdma->regs + SDMA_H_HOSTOVR);
 	dsp = readl_relaxed(sdma->regs + SDMA_H_DSPOVR);
 
-	if (dsp_override)
-		__clear_bit(channel, &dsp);
-	else
-		__set_bit(channel, &dsp);
-
-	if (event_override)
-		__clear_bit(channel, &evt);
-	else
-		__set_bit(channel, &evt);
-
-	if (mcu_override)
-		__clear_bit(channel, &mcu);
-	else
-		__set_bit(channel, &mcu);
+	__assign_bit(channel, &dsp, !dsp_override);
+	__assign_bit(channel, &evt, !event_override);
+	__assign_bit(channel, &mcu, !mcu_override);
 
 	writel_relaxed(evt, sdma->regs + SDMA_H_EVTOVR);
 	writel_relaxed(mcu, sdma->regs + SDMA_H_HOSTOVR);

-- 
2.34.1

Re: [PATCH 1/3] dmaengine: Use non-atomic bit ops for cap_mask manipulation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Switching from atomic to non-atomic bit operations for dma_cap_set() and dma_cap_clear() introduces a data race because device->cap_mask is dynamically modified and read locklessly at runtime.
--

commit c07946f79361ae1b6ffde1ddcb461591fa84c7f0
Author: Peng Fan <peng.fan@nxp.com>

dmaengine: Use non-atomic bit ops for cap_mask manipulation

This commit switches dma_cap_set() and dma_cap_clear() to use non-atomic bit
operations. The commit message assumes these functions are only called during
driver probe without concurrent access.

> dma_cap_set() and dma_cap_clear() are called exclusively during driver
> probe, before dma_async_device_register() makes the device visible to
> the rest of the system. There is no concurrent access to cap_mask at
> that point, so switch to the non-atomic __set_bit()/__clear_bit()
> equivalents.

[Severity: High]
Is the assumption that there is no concurrent access to cap_mask accurate?

Looking at dma_get_slave_channel() in drivers/dma/dmaengine.c, dma_cap_set()
is called dynamically on a registered, globally visible device:

drivers/dma/dmaengine.c:dma_get_slave_channel() {
    ...
    dma_cap_set(DMA_PRIVATE, device->cap_mask);
    ...
}

Concurrently, a reader checks the capabilities mask holding only an RCU
read lock in dma_issue_pending_all(), which races with this newly
non-atomic writer:

drivers/dma/dmaengine.c:dma_issue_pending_all() {
    ...
    if (dma_has_cap(DMA_PRIVATE, device->cap_mask))
        continue;
    ...
}

There is also a concurrent lockless read of cap_mask without holding a mutex
in __async_tx_find_channel():

crypto/async_tx/async_tx.c:__async_tx_find_channel() {
    ...
    dma_has_cap(tx_type, depend_tx->chan->device->cap_mask)
    ...
}

> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index fe33a20abc614..923d914691d06 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1551,14 +1551,14 @@ static inline bool async_tx_test_ack(struct dma_async_tx_descriptor *tx)
>  static inline void
>  __dma_cap_set(enum dma_transaction_type tx_type, dma_cap_mask_t *dstp)
>  {
> -	set_bit(tx_type, dstp->bits);
> +	__set_bit(tx_type, dstp->bits);
>  }

[Severity: High]
Because non-atomic __set_bit() and __clear_bit() can be implemented by the
compiler as read-modify-write operations, can this cause tearing or
corruption of concurrent reads and trigger KCSAN warnings or memory
corruption?

>  
>  #define dma_cap_clear(tx, mask) __dma_cap_clear((tx), &(mask))
>  static inline void
>  __dma_cap_clear(enum dma_transaction_type tx_type, dma_cap_mask_t *dstp)
>  {
> -	clear_bit(tx_type, dstp->bits);
> +	__clear_bit(tx_type, dstp->bits);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-dma-mask-v1-0-211ffd12c236@nxp.com?part=1

Re: [PATCH 3/3] dmaengine: imx-sdma: Use __assign_bit() for ownership configuration

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unsynchronized read-modify-write on global SDMA hardware registers across multiple channels.
--

commit 4ddf0614a2ae2b19c08cb7e599c4ee441c688f95
Author: Peng Fan <peng.fan@nxp.com>

dmaengine: imx-sdma: Use __assign_bit() for ownership configuration

This commit refactors sdma_config_ownership() by replacing multiple
if/else blocks containing __set_bit() and __clear_bit() with single
calls to __assign_bit().

> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 63261ab6402b9..da565409beaaa 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -710,20 +710,9 @@ static int sdma_config_ownership(struct sdma_channel *sdmac,
>  	mcu = readl_relaxed(sdma->regs + SDMA_H_HOSTOVR);
>  	dsp = readl_relaxed(sdma->regs + SDMA_H_DSPOVR);
>  
> -	if (dsp_override)
> -		__clear_bit(channel, &dsp);
> -	else
> -		__set_bit(channel, &dsp);
> -
> -	if (event_override)
> -		__clear_bit(channel, &evt);
> -	else
> -		__set_bit(channel, &evt);
> -
> -	if (mcu_override)
> -		__clear_bit(channel, &mcu);
> -	else
> -		__set_bit(channel, &mcu);
> +	__assign_bit(channel, &dsp, !dsp_override);
> +	__assign_bit(channel, &evt, !event_override);
> +	__assign_bit(channel, &mcu, !mcu_override);
>  
>  	writel_relaxed(evt, sdma->regs + SDMA_H_EVTOVR);
>  	writel_relaxed(mcu, sdma->regs + SDMA_H_HOSTOVR);

[Severity: High]
This isn't a bug introduced by this patch, but does this read-modify-write
sequence require an engine-wide lock?

If multiple DMA clients (such as serial or audio drivers) concurrently call
functions like dmaengine_slave_config() for different channels, could they
race while modifying the global SDMA_H_EVTOVR, SDMA_H_HOSTOVR, and
SDMA_H_DSPOVR hardware registers?

Since the registers are read into local variables, modified, and written back
without serialization, could concurrent calls to sdma_config_ownership() cause
one channel to inadvertently overwrite the configuration of another?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-dma-mask-v1-0-211ffd12c236@nxp.com?part=3

Re: [PATCH 2/3] dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Event mask configuration for event_id >= 32 is broken on 64-bit architectures, causing single-event DMA channels to fail.
- [High] Lockless iteration of `sdmac->terminated` in worker thread races with list modification in `sdma_terminate_all()`, causing list corruption.
--

commit 0310ee402ce9c50c678bc6f3ddf91b00a310f763
Author: Peng Fan <peng.fan@nxp.com>

dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup

In sdma_set_watermarklevel_for_p2p(), the event_mask[] fields are zeroed
in sdma_config_channel() right before this function is called, and the
channel has already been disabled. There is no concurrent access to
event_mask at this point, so replace set_bit() with __set_bit().

> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 36368835a845c..63261ab6402b9 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1241,8 +1241,8 @@ static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
>  	int lwml = sdmac->watermark_level & SDMA_WATERMARK_LEVEL_LWML;
>  	int hwml = (sdmac->watermark_level & SDMA_WATERMARK_LEVEL_HWML) >> 16;
>  
> -	set_bit(sdmac->event_id0 % 32, &sdmac->event_mask[1]);
> -	set_bit(sdmac->event_id1 % 32, &sdmac->event_mask[0]);
> +	__set_bit(sdmac->event_id0 % 32, &sdmac->event_mask[1]);
> +	__set_bit(sdmac->event_id1 % 32, &sdmac->event_mask[0]);
>  
>  	if (sdmac->event_id0 > 31)
>  		sdmac->watermark_level |= SDMA_WATERMARK_LEVEL_LWE;

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the event
mask configuration, I noticed a potential issue for single-event channels
on 64-bit architectures.

For single-event channels, sdma_config_channel() sets the bit directly:

drivers/dma/imx-sdma.c:sdma_config_channel() {
    ...
    __set_bit(sdmac->event_id0, sdmac->event_mask);
    ...
}

On 64-bit architectures, event_mask is an array of 64-bit words, so an
event_id of 32 sets bit 32 in event_mask[0]. Later in sdma_load_context(),
this value is assigned to context->gReg[1]:

drivers/dma/imx-sdma.c:sdma_load_context() {
    ...
    context->gReg[1] = sdmac->event_mask[0];
    ...
}

Since gReg elements are 32-bit (u32), the 64-bit value is truncated,
silently dropping the upper 32 bits and leaving gReg[1] as 0.

Will this cause single-event DMA channels with an event ID >= 32 to fail
completely on 64-bit platforms like i.MX8?

[Severity: High]
This is also a pre-existing issue, but I noticed a potential list corruption
in the terminate worker.

When a client calls dmaengine_terminate_all(), the driver clears sdmac->desc
and schedules the asynchronous worker sdma_channel_terminate_work().

If the client immediately submits a new descriptor, starts it, and terminates
again before the worker finishes, sdma_terminate_all() will acquire the
channel lock, execute vchan_get_all_descriptors(), and splice the new
descriptors into sdmac->terminated:

drivers/dma/imx-sdma.c:sdma_terminate_all() {
    ...
    vchan_get_all_descriptors(&sdmac->vc, &sdmac->terminated);
    ...
}

Concurrently, the worker thread locklessly iterates over and removes items
from sdmac->terminated:

drivers/dma/imx-sdma.c:sdma_channel_terminate_work() {
    ...
    vchan_dma_desc_free_list(&sdmac->vc, &sdmac->terminated);
    ...
}

Could this data race cause list corruption and lead to a kernel panic or
use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-dma-mask-v1-0-211ffd12c236@nxp.com?part=2

Re: [PATCH 0/3] dmaengine: Use non-atomic bit ops where safe

[Frank Li]

On Thu, Sep 03, 2026 at 10:16:11PM +0800, Peng Fan (OSS) wrote:
> dma_cap_set()/dma_cap_clear() and imx-sdma event_mask setup use atomic
> set_bit()/clear_bit() in contexts where no concurrent access is
> possible:
>
> - dma_cap_set()/dma_cap_clear() are called exclusively during driver
>   probe, before dma_async_device_register() makes the device visible.
> - imx-sdma event_mask[] is zeroed and configured during channel setup
>   while the channel is disabled.
>
> Switch both to non-atomic __set_bit()/__clear_bit() equivalents.

Any benefit to switch?

Frank

>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (3):
>       dmaengine: Use non-atomic bit ops for cap_mask manipulation
>       dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup
>       dmaengine: imx-sdma: Use __assign_bit() for ownership configuration
>
>  drivers/dma/imx-sdma.c    | 21 +++++----------------
>  include/linux/dmaengine.h |  4 ++--
>  2 files changed, 7 insertions(+), 18 deletions(-)
> ---
> base-commit: 89c07d98716a13454ec3fd9f97689e812cc71bd4
> change-id: 20260903-dma-mask-ddf64d770f7d
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
>

Re: [PATCH 0/3] dmaengine: Use non-atomic bit ops where safe

[Peng Fan]

On Thu, Sep 03, 2026 at 02:29:45PM -0500, Frank Li wrote:
>On Thu, Sep 03, 2026 at 10:16:11PM +0800, Peng Fan (OSS) wrote:
>> dma_cap_set()/dma_cap_clear() and imx-sdma event_mask setup use atomic
>> set_bit()/clear_bit() in contexts where no concurrent access is
>> possible:
>>
>> - dma_cap_set()/dma_cap_clear() are called exclusively during driver
>>   probe, before dma_async_device_register() makes the device visible.
>> - imx-sdma event_mask[] is zeroed and configured during channel setup
>>   while the channel is disabled.
>>
>> Switch both to non-atomic __set_bit()/__clear_bit() equivalents.
>
>Any benefit to switch?

Drop patch 1, I thought there were no cocurrent access.

For patch 2: The driver already uses the non-atomic __set_bit/__clear_bit APIs,
I think no sense to use atomic APIs in sdma_set_watermarklevel_for_p2p, or
I may miss something.

For patch 3: Use __assign_bit to save code lines.

Thanks
Peng
>
>Frank
>
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Peng Fan (3):
>>       dmaengine: Use non-atomic bit ops for cap_mask manipulation
>>       dmaengine: imx-sdma: Use non-atomic __set_bit() for event_mask setup
>>       dmaengine: imx-sdma: Use __assign_bit() for ownership configuration
>>
>>  drivers/dma/imx-sdma.c    | 21 +++++----------------
>>  include/linux/dmaengine.h |  4 ++--
>>  2 files changed, 7 insertions(+), 18 deletions(-)
>> ---
>> base-commit: 89c07d98716a13454ec3fd9f97689e812cc71bd4
>> change-id: 20260903-dma-mask-ddf64d770f7d
>>
>> Best regards,
>> --
>> Peng Fan <peng.fan@nxp.com>
>>
>
>