[PATCH 0/8] dmaengine: unmap descriptor before completing cookie

[PATCH 0/8] dmaengine: unmap descriptor before completing cookie

[Wolfram Sang]

We found out that we need to unmap descriptors before completing a
cookie [1]. Fix the drivers for which this is a no-brainer and just
switches those two function calls.

Patches are based on linux-next as of 20261009. Except one strange guy
(fsl_raid), the rest has been build-tested. Maybe these patches can be
squashed into one, not sure, I do tend to leave them separate.

There are three more drivers for which this change is not as trivial. I
probably send them out later as RFC.

Looking forward to comments! Thanks and happy hacking.

[1] https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org

Wolfram Sang (8):
  dmaengine: ptdma: unmap descriptor before completing cookie
  dmaengine: fsl_raid: unmap descriptor before completing cookie
  dmaengine: idxd: unmap descriptor before completing cookie
  dmaengine: ioat: unmap descriptor before completing cookie
  dmaengine: mv_xor_v2: unmap descriptor before completing cookie
  dmaengine: plx_dma: unmap descriptor before completing cookie
  dmaengine: switchtec-dma: unmap descriptor before completing cookie
  dmaengine: xgene-dma: unmap descriptor before completing cookie

 drivers/dma/amd/ptdma/ptdma-dmaengine.c | 4 ++--
 drivers/dma/fsl_raid.c                  | 2 +-
 drivers/dma/idxd/dma.c                  | 2 +-
 drivers/dma/ioat/dma.c                  | 6 +++---
 drivers/dma/mv_xor_v2.c                 | 3 +--
 drivers/dma/plx_dma.c                   | 4 ++--
 drivers/dma/switchtec_dma.c             | 4 ++--
 drivers/dma/xgene-dma.c                 | 2 +-
 8 files changed, 13 insertions(+), 14 deletions(-)

-- 
2.53.0

[PATCH 1/8] dmaengine: ptdma: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/amd/ptdma/ptdma-dmaengine.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/amd/ptdma/ptdma-dmaengine.c b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
index 628c49ce5de9..7f51d1e6c727 100644
--- a/drivers/dma/amd/ptdma/ptdma-dmaengine.c
+++ b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
@@ -224,8 +224,8 @@ static struct pt_dma_desc *pt_handle_active_desc(struct pt_dma_chan *chan,
 				if (desc->status != DMA_ERROR)
 					desc->status = DMA_COMPLETE;
 
-				dma_cookie_complete(tx_desc);
 				dma_descriptor_unmap(tx_desc);
+				dma_cookie_complete(tx_desc);
 				list_del(&desc->vd.node);
 			} else {
 				/* Don't handle it twice */
@@ -362,8 +362,8 @@ static void pt_cmd_callback_work(void *data, int err)
 		if (desc->status != DMA_ERROR)
 			desc->status = DMA_COMPLETE;
 
-		dma_cookie_complete(tx_desc);
 		dma_descriptor_unmap(tx_desc);
+		dma_cookie_complete(tx_desc);
 	} else {
 		tx_desc = NULL;
 	}
-- 
2.53.0

Re: [PATCH 1/8] dmaengine: ptdma: unmap descriptor before completing cookie

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: ptdma: UAF in ae4_pending_work due to unremoved list entries
--

commit 45d9a162336ad9b005d6d181ab13de82d05d7cf3
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>

dmaengine: ptdma: unmap descriptor before completing cookie

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org

> diff --git a/drivers/dma/amd/ptdma/ptdma-dmaengine.c b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> index 628c49ce5de9d..7f51d1e6c727f 100644
> --- a/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> +++ b/drivers/dma/amd/ptdma/ptdma-dmaengine.c

[ ... ]

> @@ -362,8 +362,8 @@ static void pt_cmd_callback_work(void *data, int err)
>  		if (desc->status != DMA_ERROR)
>  			desc->status = DMA_COMPLETE;
>  
> -		dma_cookie_complete(tx_desc);
>  		dma_descriptor_unmap(tx_desc);
> +		dma_cookie_complete(tx_desc);

[Severity: High]
Can this result in a use-after-free when pt_terminate_all() is called?

pt_terminate_all() extracts all descriptors from the virt-dma channel and
frees them via vchan_dma_desc_free_list():

drivers/dma/amd/ptdma/ptdma-dmaengine.c:pt_terminate_all() {
    ...
	vchan_dma_desc_free_list(&chan->vc, &head);
    ...
}

However, for AE4 DMA devices, descriptors are additionally added to the
ae4cmd_q->cmd list during pt_create_desc(). pt_terminate_all() fails to
remove the freed descriptors from this hardware pending command list, and
does not acquire ae4cmd_q->cmd_lock.

The asynchronous worker thread ae4_pending_work() then iterates over the
uncleaned list, removes the freed descriptor, and executes its callback:

drivers/dma/amd/ae4dma/ae4dma-dev.c:ae4_pending_work() {
    ...
			cmd = list_first_entry(&ae4cmd_q->cmd, struct pt_cmd, entry);
			list_del(&cmd->entry);

			ae4_check_status_error(ae4cmd_q, ae4cmd_q->dridx);
			cmd->pt_cmd_callback(cmd->data, cmd->ret);
    ...
}

Since pt_cmd_callback_work() is the callback invoked here, will this execution
dereference the freed descriptor pointers and cause list memory corruption?

>  	} else {
>  		tx_desc = NULL;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010124348.19055-1-wsa+renesas@sang-engineering.com?part=1

Re: [PATCH 1/8] dmaengine: ptdma: unmap descriptor before completing cookie

[Frank Li]

On Sat, Oct 10, 2026 at 02:43:39PM +0200, Wolfram Sang wrote:
> To ensure that buffers are flushed, make sure that the descriptor gets
> unmapped before completing the cookie.
>
> Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>  drivers/dma/amd/ptdma/ptdma-dmaengine.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/amd/ptdma/ptdma-dmaengine.c b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> index 628c49ce5de9..7f51d1e6c727 100644
> --- a/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> +++ b/drivers/dma/amd/ptdma/ptdma-dmaengine.c
> @@ -224,8 +224,8 @@ static struct pt_dma_desc *pt_handle_active_desc(struct pt_dma_chan *chan,
>  				if (desc->status != DMA_ERROR)
>  					desc->status = DMA_COMPLETE;
>
> -				dma_cookie_complete(tx_desc);
>  				dma_descriptor_unmap(tx_desc);
> +				dma_cookie_complete(tx_desc);

I think we should consider add new APIs/Helper, such as

dmaengine_unmap_and_cookie_complete(), which do both works.

Frank

>  				list_del(&desc->vd.node);
>  			} else {
>  				/* Don't handle it twice */
> @@ -362,8 +362,8 @@ static void pt_cmd_callback_work(void *data, int err)
>  		if (desc->status != DMA_ERROR)
>  			desc->status = DMA_COMPLETE;
>
> -		dma_cookie_complete(tx_desc);
>  		dma_descriptor_unmap(tx_desc);
> +		dma_cookie_complete(tx_desc);
>  	} else {
>  		tx_desc = NULL;
>  	}
> --
> 2.53.0
>

[PATCH 2/8] dmaengine: fsl_raid: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/fsl_raid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c
index 9cc289f7129e..967638e9c87e 100644
--- a/drivers/dma/fsl_raid.c
+++ b/drivers/dma/fsl_raid.c
@@ -135,8 +135,8 @@ static void fsl_re_issue_pending(struct dma_chan *chan)
 
 static void fsl_re_desc_done(struct fsl_re_desc *desc)
 {
-	dma_cookie_complete(&desc->async_tx);
 	dma_descriptor_unmap(&desc->async_tx);
+	dma_cookie_complete(&desc->async_tx);
 	dmaengine_desc_get_callback_invoke(&desc->async_tx, NULL);
 }
 
-- 
2.53.0

[PATCH 3/8] dmaengine: idxd: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/idxd/dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/idxd/dma.c b/drivers/dma/idxd/dma.c
index 9937b671f637..c3c0db9bdeb3 100644
--- a/drivers/dma/idxd/dma.c
+++ b/drivers/dma/idxd/dma.c
@@ -45,8 +45,8 @@ void idxd_dma_complete_txd(struct idxd_desc *desc,
 
 	tx = &desc->txd;
 	if (complete && tx->cookie) {
-		dma_cookie_complete(tx);
 		dma_descriptor_unmap(tx);
+		dma_cookie_complete(tx);
 		dmaengine_desc_get_callback_invoke(tx, &res);
 		tx->callback = NULL;
 		tx->callback_result = NULL;
-- 
2.53.0

[PATCH 4/8] dmaengine: ioat: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/ioat/dma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index ee93b029f9e3..1b61a7371156 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -623,8 +623,8 @@ static void __ioat_cleanup(struct ioatdma_chan *ioat_chan, dma_addr_t phys_compl
 
 		tx = &desc->txd;
 		if (tx->cookie) {
-			dma_cookie_complete(tx);
 			dma_descriptor_unmap(tx);
+			dma_cookie_complete(tx);
 			dmaengine_desc_get_callback_invoke(tx, NULL);
 			tx->callback = NULL;
 			tx->callback_result = NULL;
@@ -743,8 +743,8 @@ static void ioat_abort_descs(struct ioatdma_chan *ioat_chan)
 		if (tx->cookie) {
 			struct dmaengine_result res;
 
-			dma_cookie_complete(tx);
 			dma_descriptor_unmap(tx);
+			dma_cookie_complete(tx);
 			res.result = DMA_TRANS_ABORTED;
 			dmaengine_desc_get_callback_invoke(tx, &res);
 			tx->callback = NULL;
@@ -846,8 +846,8 @@ static void ioat_eh(struct ioatdma_chan *ioat_chan)
 	/* cleanup the faulty descriptor since we are continuing */
 	tx = &desc->txd;
 	if (tx->cookie) {
-		dma_cookie_complete(tx);
 		dma_descriptor_unmap(tx);
+		dma_cookie_complete(tx);
 		dmaengine_desc_get_callback_invoke(tx, &res);
 		tx->callback = NULL;
 		tx->callback_result = NULL;
-- 
2.53.0

[PATCH 5/8] dmaengine: mv_xor_v2: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/mv_xor_v2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
index cad4d4fb51ac..8a307431721f 100644
--- a/drivers/dma/mv_xor_v2.c
+++ b/drivers/dma/mv_xor_v2.c
@@ -581,9 +581,8 @@ static void mv_xor_v2_tasklet(struct tasklet_struct *t)
 			 * lock is required the IMSG threshold provide
 			 * the locking
 			 */
-			dma_cookie_complete(&next_pending_sw_desc->async_tx);
-
 			dma_descriptor_unmap(&next_pending_sw_desc->async_tx);
+			dma_cookie_complete(&next_pending_sw_desc->async_tx);
 			dmaengine_desc_get_callback_invoke(
 					&next_pending_sw_desc->async_tx, NULL);
 		}
-- 
2.53.0

Re: [PATCH 5/8] dmaengine: mv_xor_v2: unmap descriptor before completing cookie

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: UAF race from calling dmaengine_desc_get_callback_invoke late
--

commit 8c7213cd37abe1e50d7719fbacf46e143cda1fb6
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>

dmaengine: mv_xor_v2: unmap descriptor before completing cookie

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org

> diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
> index cad4d4fb51ac3..8a307431721fc 100644
> --- a/drivers/dma/mv_xor_v2.c
> +++ b/drivers/dma/mv_xor_v2.c
> @@ -581,9 +581,8 @@ static void mv_xor_v2_tasklet(struct tasklet_struct *t)
>  			 * lock is required the IMSG threshold provide
>  			 * the locking
>  			 */
> -			dma_cookie_complete(&next_pending_sw_desc->async_tx);
> -
>  			dma_descriptor_unmap(&next_pending_sw_desc->async_tx);
> +			dma_cookie_complete(&next_pending_sw_desc->async_tx);
>  			dmaengine_desc_get_callback_invoke(
>  					&next_pending_sw_desc->async_tx, NULL);
>  		}

[Severity: High]
Does completing the cookie before extracting the callback information create a
use-after-free race condition?

dma_cookie_complete() updates tx->chan->completed_cookie, which makes the DMA
transaction completion visible to clients polling via dma_async_is_tx_complete().

After completion is signaled, clients are legally allowed to free the callback
context (callback_param), recycle resources, or even unload the module
containing the callback function.

If a polling client races and frees the resources immediately after seeing
completion, the subsequent call to dmaengine_desc_get_callback_invoke() could
dereference a freed callback_param or jump to unmapped module memory.

Should the callback information be cached using dmaengine_desc_get_callback()
before calling dma_cookie_complete(), and then invoked via
dmaengine_desc_callback_invoke() afterwards?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010124348.19055-1-wsa+renesas@sang-engineering.com?part=5

[PATCH 6/8] dmaengine: plx_dma: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/plx_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/plx_dma.c b/drivers/dma/plx_dma.c
index 409898e92c32..7b0fd9843b6a 100644
--- a/drivers/dma/plx_dma.c
+++ b/drivers/dma/plx_dma.c
@@ -156,8 +156,8 @@ static void plx_dma_process_desc(struct plx_dma_dev *plxdev)
 		else
 			res.result = DMA_TRANS_READ_FAILED;
 
-		dma_cookie_complete(&desc->txd);
 		dma_descriptor_unmap(&desc->txd);
+		dma_cookie_complete(&desc->txd);
 		dmaengine_desc_get_callback_invoke(&desc->txd, &res);
 		desc->txd.callback = NULL;
 		desc->txd.callback_result = NULL;
@@ -183,8 +183,8 @@ static void plx_dma_abort_desc(struct plx_dma_dev *plxdev)
 		res.residue = desc->orig_size;
 		res.result = DMA_TRANS_ABORTED;
 
-		dma_cookie_complete(&desc->txd);
 		dma_descriptor_unmap(&desc->txd);
+		dma_cookie_complete(&desc->txd);
 		dmaengine_desc_get_callback_invoke(&desc->txd, &res);
 		desc->txd.callback = NULL;
 		desc->txd.callback_result = NULL;
-- 
2.53.0

Re: [PATCH 6/8] dmaengine: plx_dma: unmap descriptor before completing cookie

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dmaengine: plx_dma: deadlock in plx_dma_process_desc due to missing _bh
- [High] dmaengine: plx_dma: recursive deadlock when client submits from callback
--

commit ad3cf51e19996d2f8cb3cdd66ceba6e9d034f3e7
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>

dmaengine: plx_dma: unmap descriptor before completing cookie

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org

> diff --git a/drivers/dma/plx_dma.c b/drivers/dma/plx_dma.c
> index 409898e92c320..7b0fd9843b6a1 100644
> --- a/drivers/dma/plx_dma.c
> +++ b/drivers/dma/plx_dma.c
> @@ -156,8 +156,8 @@ static void plx_dma_process_desc(struct plx_dma_dev *plxdev)
>  		else
>  			res.result = DMA_TRANS_READ_FAILED;
>  
> -		dma_cookie_complete(&desc->txd);
>  		dma_descriptor_unmap(&desc->txd);
> +		dma_cookie_complete(&desc->txd);
>  		dmaengine_desc_get_callback_invoke(&desc->txd, &res);

[Severity: High]
Is it possible for a deadlock to occur here due to how ring_lock is acquired?

In plx_dma_process_desc(), ring_lock is acquired using spin_lock() without
disabling bottom halves. If it is called from process context via
plx_dma_tx_status() or plx_dma_abort_desc() and is interrupted by the
plx_dma_desc_task() tasklet, the tasklet will attempt to acquire ring_lock
on the same CPU.

[Severity: High]
Does this code risk a recursive deadlock if a client submits a new
transaction from its completion callback?

plx_dma_process_desc() invokes the client callback synchronously while
holding ring_lock. If a client callback queues the next transaction via
dmaengine_prep_dma_memcpy(), it will enter plx_dma_prep_memcpy() which
attempts to acquire ring_lock again, deadlocking on the same CPU:

drivers/dma/plx_dma.c:plx_dma_prep_memcpy() {
    ...
    spin_lock_bh(&plxdev->ring_lock);
    ...
}

Standard DMA engine patterns require drivers to drop their primary locks
before invoking client callbacks.

>  		desc->txd.callback = NULL;
>  		desc->txd.callback_result = NULL;
> @@ -183,8 +183,8 @@ static void plx_dma_abort_desc(struct plx_dma_dev *plxdev)
>  		res.residue = desc->orig_size;
>  		res.result = DMA_TRANS_ABORTED;
>  
> -		dma_cookie_complete(&desc->txd);
>  		dma_descriptor_unmap(&desc->txd);
> +		dma_cookie_complete(&desc->txd);
>  		dmaengine_desc_get_callback_invoke(&desc->txd, &res);

[Severity: High]
Can a recursive deadlock also happen during abort operations?

Similar to plx_dma_process_desc(), plx_dma_abort_desc() invokes the client
callback synchronously while holding ring_lock (acquired via
spin_lock_bh()). A client queuing a new transaction from this callback
would attempt to acquire the same lock.

>  		desc->txd.callback = NULL;
>  		desc->txd.callback_result = NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010124348.19055-1-wsa+renesas@sang-engineering.com?part=6

[PATCH 7/8] dmaengine: switchtec-dma: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/switchtec_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/switchtec_dma.c b/drivers/dma/switchtec_dma.c
index a386c3a284e6..84a0a2e5e872 100644
--- a/drivers/dma/switchtec_dma.c
+++ b/drivers/dma/switchtec_dma.c
@@ -486,8 +486,8 @@ switchtec_dma_cleanup_completed(struct switchtec_dma_chan *swdma_chan)
 		}
 
 		do {
-			dma_cookie_complete(&desc->txd);
 			dma_descriptor_unmap(&desc->txd);
+			dma_cookie_complete(&desc->txd);
 			dmaengine_desc_get_callback_invoke(&desc->txd, &res);
 			desc->txd.callback = NULL;
 			desc->txd.callback_result = NULL;
@@ -529,8 +529,8 @@ switchtec_dma_abort_desc(struct switchtec_dma_chan *swdma_chan, int force)
 		res.residue = desc->orig_size;
 		res.result = DMA_TRANS_ABORTED;
 
-		dma_cookie_complete(&desc->txd);
 		dma_descriptor_unmap(&desc->txd);
+		dma_cookie_complete(&desc->txd);
 		if (!force)
 			dmaengine_desc_get_callback_invoke(&desc->txd, &res);
 		desc->txd.callback = NULL;
-- 
2.53.0

Re: [PATCH 7/8] dmaengine: switchtec-dma: unmap descriptor before completing cookie

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: switchtec-dma: recursive deadlock when invoking callback with complete_lock held
--

commit ffea26942d7e62541800c95b1e3d4d09f66f0c18
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>

dmaengine: switchtec-dma: unmap descriptor before completing cookie

This commit ensures that the descriptor gets unmapped before completing the
cookie to ensure that buffers are flushed.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org

> diff --git a/drivers/dma/switchtec_dma.c b/drivers/dma/switchtec_dma.c
> index a386c3a284e6e..84a0a2e5e8722 100644
> --- a/drivers/dma/switchtec_dma.c
> +++ b/drivers/dma/switchtec_dma.c
> @@ -486,8 +486,8 @@ switchtec_dma_cleanup_completed(struct switchtec_dma_chan *swdma_chan)
>  		}
>  
>  		do {
> -			dma_cookie_complete(&desc->txd);
>  			dma_descriptor_unmap(&desc->txd);
> +			dma_cookie_complete(&desc->txd);
>  			dmaengine_desc_get_callback_invoke(&desc->txd, &res);

[Severity: High]
Can this lead to a recursive deadlock if the client callback queries the DMA
status or terminates the transfer?

In switchtec_dma_cleanup_completed(), complete_lock is acquired earlier in the
function. If the DMA client's completion callback invokes dmaengine_tx_status()
or dmaengine_terminate_all(), those APIs will call into the driver's
switchtec_dma_tx_status() or switchtec_dma_terminate_all() functions.

switchtec_dma_tx_status() calls switchtec_dma_cleanup_completed(), which
attempts to re-acquire complete_lock.

switchtec_dma_terminate_all() also attempts to acquire complete_lock directly:

switchtec_dma_terminate_all()
    spin_lock_bh(&swdma_chan->complete_lock);

Since spin_lock_bh is not recursive, would this result in a deadlock?

>  			desc->txd.callback = NULL;
>  			desc->txd.callback_result = NULL;
[ ... ]
> @@ -529,8 +529,8 @@ switchtec_dma_abort_desc(struct switchtec_dma_chan *swdma_chan, int force)
>  		res.residue = desc->orig_size;
>  		res.result = DMA_TRANS_ABORTED;
>  
> -		dma_cookie_complete(&desc->txd);
>  		dma_descriptor_unmap(&desc->txd);
> +		dma_cookie_complete(&desc->txd);
>  		if (!force)
>  			dmaengine_desc_get_callback_invoke(&desc->txd, &res);

[Severity: High]
Does this code have the same deadlock regression as switchtec_dma_cleanup_completed()
since complete_lock is also held when switchtec_dma_abort_desc() invokes the
callback?

>  		desc->txd.callback = NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010124348.19055-1-wsa+renesas@sang-engineering.com?part=7

[PATCH 8/8] dmaengine: xgene-dma: unmap descriptor before completing cookie

[Wolfram Sang]

To ensure that buffers are flushed, make sure that the descriptor gets
unmapped before completing the cookie.

Link: https://lore.kernel.org/r/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/dma/xgene-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 8d1c58ca0d48..698d7ca7ff7f 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -548,8 +548,8 @@ static void xgene_dma_run_tx_complete_actions(struct xgene_dma_chan *chan,
 	if (tx->cookie == 0)
 		return;
 
-	dma_cookie_complete(tx);
 	dma_descriptor_unmap(tx);
+	dma_cookie_complete(tx);
 
 	/* Run the link descriptor callback function */
 	dmaengine_desc_get_callback_invoke(tx, NULL);
-- 
2.53.0

Re: [PATCH 0/8] dmaengine: unmap descriptor before completing cookie

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]


> We found out that we need to unmap descriptors before completing a
> cookie [1]. Fix the drivers for which this is a no-brainer and just
> switches those two function calls.

Okay, according to Sashiko, patches 1+5+6+7 are no no-brainers but need
a deeper analysis which I am not able to provide.

So, we could drop this series entirely because it seems more trustworthy
to let people with actual hardware fix these issues. Maybe a FIXME could
be added instead to these drivers.

Or, we can apply at least patches 2+3+4+8 where Sashiko found no issues.

I tend to use the first option but am open to whatever maintainers think
about it.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]