linux-kernel - Re: [PATCH v2 6/8] nvmet: pci-epf: Use dmaengine_prep_config_single

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0fa95ea2-4539-472b-adae-300e46a78f20@kernel.org>
Date: Fri, 19 Dec 2025 19:42:57 +0900
From: Damien Le Moal <dlemoal@...nel.org>
To: Frank Li <Frank.Li@....com>, Vinod Koul <vkoul@...nel.org>,
 Manivannan Sadhasivam <mani@...nel.org>,
 Krzysztof Wilczyński <kwilczynski@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>, Christoph Hellwig <hch@....de>,
 Sagi Grimberg <sagi@...mberg.me>, Chaitanya Kulkarni <kch@...dia.com>,
 Herbert Xu <herbert@...dor.apana.org.au>,
 "David S. Miller" <davem@...emloft.net>,
 Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>, Koichiro Den <den@...inux.co.jp>,
 Niklas Cassel <cassel@...nel.org>
Cc: dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-nvme@...ts.infradead.org,
 mhi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
 linux-crypto@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 imx@...ts.linux.dev
Subject: Re: [PATCH v2 6/8] nvmet: pci-epf: Use
 dmaengine_prep_config_single_safe() API

On 12/19/25 00:56, Frank Li wrote:
> Use the new dmaengine_prep_config_single_safe() API to combine the
> configuration and descriptor preparation into a single call.
> 
> Since dmaengine_prep_config_single_safe() performs the configuration and
> preparation atomically and dw edma driver implement prep_config_sg() call
> back, so dmaengine_prep_config_single() is reentriable, the mutex can be
> removed.

What about for platforms other than DesignWare EDMA ?
This is a generic endpoint driver that can work on any platform that is endpoint
capable and that has a DMA channel for the PCI endpoint.

The dmaengine_prep_config_single_safe() API should be handling everything
transparently for any platform, regardless of the DMA channel driver
implementing or not the prep_config_sg() callback.

For platforms that do not implement it, I suspect that the mutex will still be
needed here. So how to we resolve this ? Ideally, all of that should be hidden
by the DMA API. The endpoint driver should not need to deal with these differences.

> 
> Tested-by: Niklas Cassel <cassel@...nel.org>
> Signed-off-by: Frank Li <Frank.Li@....com>
> ---
>  drivers/nvme/target/pci-epf.c | 18 ++++--------------
>  1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 56b1c6a7706a9e2dd9d8aaf17b440129b948486c..8b5ea5d4c79dfd461b767cfd4033a9e4604c94b1 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -388,22 +388,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  		return -EINVAL;
>  	}
>  
> -	mutex_lock(lock);
> -
>  	dma_dev = dmaengine_get_dma_device(chan);
>  	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
>  	ret = dma_mapping_error(dma_dev, dma_addr);
>  	if (ret)
> -		goto unlock;
> -
> -	ret = dmaengine_slave_config(chan, &sconf);
> -	if (ret) {
> -		dev_err(dev, "Failed to configure DMA channel\n");
> -		goto unmap;
> -	}
> +		return ret;
>  
> -	desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
> -					   sconf.direction, DMA_CTRL_ACK);
> +	desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
> +						 sconf.direction,
> +						 DMA_CTRL_ACK, &sconf);
>  	if (!desc) {
>  		dev_err(dev, "Failed to prepare DMA\n");
>  		ret = -EIO;
> @@ -426,9 +419,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>  
> -unlock:
> -	mutex_unlock(lock);
> -
>  	return ret;
>  }
>  
> 

-- 
Damien Le Moal
Western Digital Research