From: sashiko-bot@kernel.org
To: "Wolfram Sang" <wsa+renesas@sang-engineering.com>
Cc: vkoul@kernel.org, dmaengine@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH 7/8] dmaengine: switchtec-dma: unmap descriptor before completing cookie
Date: Sat, 10 Oct 2026 12:54:05 +0000 [thread overview]
Message-ID: <sashiko-outbox-166551@kernel.org> (raw)
In-Reply-To: <20261010124348.19055-8-wsa+renesas@sang-engineering.com>
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
next prev parent reply other threads:[~2026-10-10 12:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 12:43 [PATCH 0/8] dmaengine: unmap descriptor before completing cookie Wolfram Sang
2026-10-10 12:43 ` [PATCH 1/8] dmaengine: ptdma: " Wolfram Sang
2026-10-10 12:57 ` sashiko-bot
2026-10-12 14:51 ` Frank Li
2026-10-10 12:43 ` [PATCH 2/8] dmaengine: fsl_raid: " Wolfram Sang
2026-10-10 12:43 ` [PATCH 3/8] dmaengine: idxd: " Wolfram Sang
2026-10-13 22:54 ` Vinicius Costa Gomes
2026-10-10 12:43 ` [PATCH 4/8] dmaengine: ioat: " Wolfram Sang
2026-10-10 12:43 ` [PATCH 5/8] dmaengine: mv_xor_v2: " Wolfram Sang
2026-10-10 12:54 ` sashiko-bot
2026-10-10 12:43 ` [PATCH 6/8] dmaengine: plx_dma: " Wolfram Sang
2026-10-10 12:56 ` sashiko-bot
2026-10-13 20:06 ` Logan Gunthorpe
2026-10-10 12:43 ` [PATCH 7/8] dmaengine: switchtec-dma: " Wolfram Sang
2026-10-10 12:54 ` sashiko-bot [this message]
2026-10-13 20:06 ` Logan Gunthorpe
2026-10-10 12:43 ` [PATCH 8/8] dmaengine: xgene-dma: " Wolfram Sang
2026-10-12 10:42 ` [PATCH 0/8] dmaengine: " Wolfram Sang
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=sashiko-outbox-166551@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
--cc=wsa+renesas@sang-engineering.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.