All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: imx@lists.linux.dev, vkoul@kernel.org, linux-pci@vger.kernel.org,
	dmaengine@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v7 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
Date: Thu, 21 May 2026 18:31:06 +0000	[thread overview]
Message-ID: <20260521183107.0690C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260521-dma_prep_config-v7-6-1f73f4899883@nxp.com>

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

Pre-existing issues:
- [High] Directly mapping embedded, non-cacheline-aligned struct fields (`cmd`) for DMA causes cacheline sharing corruption on non-cache-coherent architectures.
--

commit bb3da580c11e6aae50b53789fc87a1f21f670249
Author: Frank Li <Frank.Li@nxp.com>

nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer

This commit removes unnecessary dmaengine_terminate_sync() calls from the
success path of DMA transfers, leaving them only in the error path.

> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 4e9db96ebfecd..2afe8f4d0e461 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -420,10 +420,9 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,

[Severity: High]
This is a pre-existing issue, but does mapping this buffer for DMA cause
cacheline sharing corruption on non-coherent architectures?

In nvmet_pci_epf_process_sq(), a pointer to the embedded cmd field of
struct nvmet_pci_epf_iod is passed to nvmet_pci_epf_transfer() with
DMA_FROM_DEVICE. This eventually reaches nvmet_pci_epf_dma_transfer(),
where the buffer is mapped via dma_map_single().

Because cmd is not marked with ____cacheline_aligned in
struct nvmet_pci_epf_iod, it shares cachelines with actively modified
adjacent fields like req and cqe. When dma_map_single() invalidates
the cachelines spanning cmd, any pending CPU writes to adjacent fields
are discarded.

Could this lead to the CPU later reading stale or uninitialized memory when
accessing iod->req or other adjacent fields?

>  	if (dma_sync_wait(chan, cookie) != DMA_COMPLETE) {
>  		dev_err(dev, "DMA transfer failed\n");
>  		ret = -EIO;
> +		dmaengine_terminate_sync(chan);
>  	}
>  
> -	dmaengine_terminate_sync(chan);
> -
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com?part=6

  reply	other threads:[~2026-05-21 18:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-21 15:32 [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation Frank.Li
2026-05-21 15:32 ` [PATCH v7 1/9] dmaengine: Add API to combine configuration and preparation (sg and single) Frank.Li
2026-05-21 15:32 ` [PATCH v7 2/9] dmaengine: Add safe API to combine configuration and preparation Frank.Li
2026-05-21 17:10   ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code Frank.Li
2026-05-21 17:31   ` sashiko-bot
2026-07-09 19:52   ` Bjorn Helgaas
2026-07-14 12:11     ` Vinod Koul
2026-05-21 15:32 ` [PATCH v7 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback Frank.Li
2026-05-21 17:56   ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer() Frank.Li
2026-05-21 18:10   ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer Frank.Li
2026-05-21 18:31   ` sashiko-bot [this message]
2026-05-21 15:32 ` [PATCH v7 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API Frank.Li
2026-05-21 19:05   ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code Frank.Li
2026-05-21 15:32 ` [PATCH v7 9/9] crypto: atmel: Use dmaengine_prep_config_sg() API Frank.Li
2026-07-02 15:26 ` [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation Vinod Koul

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=20260521183107.0690C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=Frank.Li@oss.nxp.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=linux-pci@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 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.