From: Frank Li <Frank.li@oss.nxp.com>
To: Daniel Byrne <daniel1.byrne@intel.com>
Cc: Vinod Koul <vkoul@kernel.org>, Dave Jiang <dave.jiang@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>, Dan Williams <djbw@kernel.org>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
Frank Li <Frank.Li@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Kristen Accardi <kristen.c.accardi@intel.com>,
dmaengine@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 03/17] dmaengine: idxd: refuse a memcpy longer than the WQ max transfer size
Date: Mon, 19 Oct 2026 16:19:54 -0500 [thread overview]
Message-ID: <ataJeqa4jhxeKpym@SMW015318> (raw)
In-Reply-To: <20261019150630.4026341-4-daniel1.byrne@intel.com>
On Mon, Oct 19, 2026 at 08:06:16AM -0700, Daniel Byrne wrote:
> [You don't often get email from daniel1.byrne@intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> idxd_dma_submit_memcpy() checks the length only against the device
> limit from GENCAP. Since commit d7aad5550eca ("dmaengine: idxd: add
> support for configurable max wq xfer size"), WQCFG is programmed with
> the work queue's own max_transfer_size instead, and that is the limit
> the hardware enforces. Since commit 92452a72ebdf ("dmaengine: idxd: set
> defaults for wq configs"), that limit defaults to 2 MiB.
>
> A copy longer than the work queue's limit is therefore accepted at prep
> time and then fails in hardware with DSA_COMP_XFER_ERANGE. A client that
> sets only tx->callback cannot see that error, so the copy looks
> complete. Also check the work queue's limit, so that prep returns NULL
> and the caller can fall back.
>
> On a Granite Rapids DSA with the default 2 MiB work queue limit and a
> device limit of 2 GiB, dmatest with norandom=1 and test_buf_size=4194304
> reports a data error for every copy on v7.2: the destination is never
> written, yet each copy completes. With this change the same test fails
> at prep, and copies of 1 MiB and 2 MiB pass as before.
>
> Fixes: d7aad5550eca ("dmaengine: idxd: add support for configurable max wq xfer size")
> Cc: stable@vger.kernel.org # 5.10+
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Daniel Byrne <daniel1.byrne@intel.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/idxd/dma.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/idxd/dma.c b/drivers/dma/idxd/dma.c
> index 9937b671f637..c116416e10e5 100644
> --- a/drivers/dma/idxd/dma.c
> +++ b/drivers/dma/idxd/dma.c
> @@ -115,7 +115,8 @@ idxd_dma_submit_memcpy(struct dma_chan *c, dma_addr_t dma_dest,
> if (wq->state != IDXD_WQ_ENABLED)
> return NULL;
>
> - if (len > idxd->max_xfer_bytes)
> + /* The work queue's configured limit is what the hardware enforces. */
> + if (len > idxd->max_xfer_bytes || len > wq->max_xfer_bytes)
> return NULL;
>
> op_flag_setup(flags, &desc_flags);
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-10-19 21:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 15:06 [PATCH 00/17] [PATCH 00/17] dmaengine: idxd: fixes found by an in-kernel polling client Daniel Byrne
2026-10-19 15:06 ` [PATCH 01/17] dmaengine: idxd: don't queue EVL fault work for kernel WQs Daniel Byrne
2026-10-19 15:06 ` [PATCH 02/17] dmaengine: idxd: detach the user fault workqueue under the event log lock Daniel Byrne
2026-10-19 15:06 ` [PATCH 03/17] dmaengine: idxd: refuse a memcpy longer than the WQ max transfer size Daniel Byrne
2026-10-19 21:19 ` Frank Li [this message]
2026-10-19 15:06 ` [PATCH 04/17] dmaengine: idxd: list a new channel only once it is complete Daniel Byrne
2026-10-19 15:06 ` [PATCH 05/17] dmaengine: idxd: unbind the device driver before its work queues go away Daniel Byrne
2026-10-19 15:06 ` [PATCH 06/17] dmaengine: idxd: keep the interrupt handle across terminate_all Daniel Byrne
2026-10-19 15:06 ` [PATCH 07/17] dmaengine: idxd: bound device command waits and fail fast after a timeout Daniel Byrne
2026-10-19 17:05 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 08/17] dmaengine: idxd: compare the device disable status code whole Daniel Byrne
2026-10-19 15:06 ` [PATCH 09/17] dmaengine: idxd: quarantine terminate_all's descriptor slots until the device has drained Daniel Byrne
2026-10-19 17:26 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 10/17] dmaengine: idxd: return -ETIMEDOUT from drains and resets and leak what the device may still write Daniel Byrne
2026-10-19 17:50 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 11/17] dmaengine: idxd: disable the device before its work queues are unregistered Daniel Byrne
2026-10-19 18:09 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 12/17] dmaengine: idxd: hold device commands off while the reset re-creates its interrupts Daniel Byrne
2026-10-19 18:19 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 13/17] dmaengine: idxd: fix the double free of a descriptor whose submission failed Daniel Byrne
2026-10-19 15:06 ` [PATCH 14/17] dmaengine: idxd: complete an iaa_crypto descriptor through its own driver on abort and flush Daniel Byrne
2026-10-19 18:56 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 15/17] dmaengine: idxd: flush the work queues on every halt type Daniel Byrne
2026-10-19 19:17 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 16/17] dmaengine: idxd: keep client callbacks on a halt flush and cancel resubmissions after a terminate Daniel Byrne
2026-10-19 19:36 ` sashiko-bot
2026-10-19 15:06 ` [PATCH 17/17] dmaengine: idxd: run the interrupt-handle revoke under the queue lock Daniel Byrne
2026-10-19 19:53 ` sashiko-bot
2026-10-19 19:09 ` [PATCH 00/17] [PATCH 00/17] dmaengine: idxd: fixes found by an in-kernel polling client Frank Li
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=ataJeqa4jhxeKpym@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=Frank.Li@kernel.org \
--cc=daniel1.byrne@intel.com \
--cc=dave.jiang@intel.com \
--cc=djbw@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=fenghua.yu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=kristen.c.accardi@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tom.zanussi@linux.intel.com \
--cc=vinicius.gomes@intel.com \
--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 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.