From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: Frank.Li@kernel.org, vkoul@kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v22 13/14] crypto: qce - Add BAM DMA support for crypto register I/O
Date: Fri, 17 Jul 2026 09:08:40 +0000 [thread overview]
Message-ID: <20260717090840.8F9861F00A3F@smtp.kernel.org> (raw)
In-Reply-To: <20260717-qcom-qce-cmd-descr-v22-13-ff0d18b27246@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] BAM DMA command descriptors misinterpret host-endian values on big-endian architectures, causing incorrect register writes.
Pre-existing issues:
- [High] The error cleanup path in `qce_aead_async_req_handle` unmaps the wrong scatterlist for the source buffer when `diff_dst` is true, leaking associated data mappings.
- [High] Incorrect error check for `dma_map_sg()` allows an unmapped scatterlist to be erroneously unmapped on fallback paths.
--
--- Patch [13]: [PATCH v22 13/14] crypto: qce - Add BAM DMA support for crypto register I/O ---
commit 61e73b38a77173b6ebf2858f2dd73a186ca5b139
Author: Bartosz Golaszewski <brgl@kernel.org>
crypto: qce - Add BAM DMA support for crypto register I/O
This commit switches the driver to use BAM DMA for register I/O instead of
direct register writes. It provides the necessary DMA infrastructure, updates
the ordering of operations, and replaces direct I/O calls with wrappers that
queue DMA command descriptors.
> diff --git a/drivers/crypto/qce/aead.c b/drivers/crypto/qce/aead.c
> index 92d84941d3dbf..48ea7fb9a91e6 100644
> --- a/drivers/crypto/qce/aead.c
> +++ b/drivers/crypto/qce/aead.c
> @@ -461,17 +461,17 @@ qce_aead_async_req_handle(struct crypto_async_request *async_req)
> src_nents = dst_nents - 1;
> }
>
> - ret = qce_dma_prep_sgs(&qce->dma, rctx->src_sg, src_nents, rctx->dst_sg, dst_nents,
> - qce_aead_done, async_req);
> + ret = qce_start(async_req, tmpl->crypto_alg_type);
> if (ret)
> goto error_unmap_src;
[Severity: High]
This is a pre-existing issue, but is the error check for dma_map_sg()
correct prior to this step?
Looking earlier in qce_aead_async_req_handle():
src_nents = dma_map_sg(qce->dev, rctx->src_sg, rctx->src_nents, dir_src);
if (src_nents < 0) {
ret = src_nents;
goto error_unmap_dst;
}
Since dma_map_sg() returns 0 on failure, checking for < 0 bypasses this error
handler. This allows an unmapped scatterlist to proceed and later be
erroneously unmapped on fallback paths (such as if qce_start or
qce_dma_prep_sgs fails).
[Severity: High]
This is also a pre-existing issue, but does this error path unmap the wrong
scatterlist when diff_dst is true?
In qce_aead_async_req_handle(), the source buffer is mapped using:
src_nents = dma_map_sg(qce->dev, rctx->src_sg, rctx->src_nents, dir_src);
However, if a subsequent step fails and execution jumps to error_unmap_src,
the code performs:
error_unmap_src:
if (diff_dst)
dma_unmap_sg(qce->dev, req->src, rctx->src_nents, dir_src);
Could this leak IOMMU mappings by unmapping req->src instead of the actually
mapped rctx->src_sg buffer?
[ ... ]
> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index 26347e9fc078a..88d253d9147cf 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c
> @@ -11,6 +13,98 @@
> #include "dma.h"
>
> #define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
> +#define QCE_BAM_CMD_SGL_SIZE 128
[ ... ]
> +static void qce_prep_dma_cmd_desc(struct qce_device *qce, struct qce_dma_data *dma,
> + unsigned int addr, void *buf)
> +{
> + struct qce_bam_transaction *bam_txn = dma->bam_txn;
> + struct bam_cmd_element *bam_ce_buf;
> + int bam_ce_size, cnt, idx;
> +
> + idx = bam_txn->bam_ce_idx;
> + bam_ce_buf = &bam_txn->bam_ce[idx];
> + bam_prep_ce_le32(bam_ce_buf, addr, BAM_WRITE_COMMAND, *((__le32 *)buf));
[Severity: High]
Does this direct cast incorrectly handle host-endian values on big-endian
architectures?
The buf parameter is passed a native u32 pointer from qce_write_dma():
unsigned int reg_addr = ((unsigned int)(qce->base_phys) + offset);
qce_prep_dma_cmd_desc(qce, &qce->dma, reg_addr, &val);
By casting the native u32 to *((__le32 *)buf) without applying cpu_to_le32(),
the little-endian BAM DMA hardware might receive reversed byte sequences for
crypto register writes on big-endian systems.
> +
> + bam_ce_buf = &bam_txn->bam_ce[bam_txn->pre_bam_ce_idx];
> + bam_txn->bam_ce_idx++;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-qcom-qce-cmd-descr-v22-0-ff0d18b27246@oss.qualcomm.com?part=13
next prev parent reply other threads:[~2026-07-17 9:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 8:36 [PATCH v22 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 01/14] dmaengine: constify struct dma_descriptor_metadata_ops Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 02/14] dmaengine: qcom: bam_dma: free interrupt before the clock in error path Bartosz Golaszewski
2026-07-17 8:50 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 03/14] dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue Bartosz Golaszewski
2026-07-17 8:53 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 04/14] dmaengine: qcom: bam_dma: Extend the driver's device match data Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 05/14] dmaengine: qcom: bam_dma: Add pipe_lock_supported flag support Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 06/14] dmaengine: qcom: bam_dma: add support for BAM locking Bartosz Golaszewski
2026-07-17 8:51 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 07/14] crypto: qce - Cancel work on device detach Bartosz Golaszewski
2026-07-17 8:56 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 08/14] crypto: qce - Include algapi.h in the core.h header Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 09/14] crypto: qce - Remove unused ignore_buf Bartosz Golaszewski
2026-07-17 8:54 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 10/14] crypto: qce - Simplify arguments of devm_qce_dma_request() Bartosz Golaszewski
2026-07-17 8:36 ` [PATCH v22 11/14] crypto: qce - Use existing devres APIs in devm_qce_dma_request() Bartosz Golaszewski
2026-07-17 9:05 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 12/14] crypto: qce - Map crypto memory for DMA Bartosz Golaszewski
2026-07-17 9:02 ` sashiko-bot
2026-07-17 8:36 ` [PATCH v22 13/14] crypto: qce - Add BAM DMA support for crypto register I/O Bartosz Golaszewski
2026-07-17 9:08 ` sashiko-bot [this message]
2026-07-17 8:36 ` [PATCH v22 14/14] crypto: qce - Communicate the base physical address to the dmaengine Bartosz Golaszewski
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=20260717090840.8F9861F00A3F@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=dmaengine@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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