linux-kernel - Re: [RFC PATCH v1 18/18] nvme-pci: use new dma API

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: <249ec228-4ffd-4121-bd51-f4a19275fee1@arm.com>
Date: Thu, 4 Jul 2024 16:23:47 +0100
From: Robin Murphy <robin.murphy@....com>
To: Leon Romanovsky <leon@...nel.org>, Jens Axboe <axboe@...nel.dk>,
 Jason Gunthorpe <jgg@...pe.ca>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Keith Busch <kbusch@...nel.org>,
 Christoph Hellwig <hch@....de>, "Zeng, Oak" <oak.zeng@...el.com>,
 Chaitanya Kulkarni <kch@...dia.com>
Cc: Sagi Grimberg <sagi@...mberg.me>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Logan Gunthorpe <logang@...tatee.com>, Yishai Hadas <yishaih@...dia.com>,
 Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>,
 Kevin Tian <kevin.tian@...el.com>,
 Alex Williamson <alex.williamson@...hat.com>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Jérôme Glisse <jglisse@...hat.com>,
 Andrew Morton <akpm@...ux-foundation.org>, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
 iommu@...ts.linux.dev, linux-nvme@...ts.infradead.org,
 linux-pci@...r.kernel.org, kvm@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH v1 18/18] nvme-pci: use new dma API

On 02/07/2024 10:09 am, Leon Romanovsky wrote:
[...]
> +static inline dma_addr_t nvme_dma_link_page(struct page *page,
> +					   unsigned int poffset,
> +					   unsigned int len,
> +					   struct nvme_iod *iod)
>   {
> -	int i;
> -	struct scatterlist *sg;
> +	struct dma_iova_attrs *iova = &iod->dma_map->iova;
> +	struct dma_iova_state *state = &iod->dma_map->state;
> +	dma_addr_t dma_addr;
> +	int ret;
> +
> +	if (iod->dma_map->use_iova) {
> +		phys_addr_t phys = page_to_phys(page) + poffset;

Yeah, there's no way this can possibly work. You can't do the 
dev_use_swiotlb() check up-front based on some overall DMA operation 
size, but then build that operation out of arbitrarily small fragments 
of different physical pages that *could* individually need bouncing to 
not break coherency.

Thanks,
Robin.

> +
> +		dma_addr = state->iova->addr + state->range_size;
> +		ret = dma_link_range(&iod->dma_map->state, phys, len);
> +		if (ret)
> +			return DMA_MAPPING_ERROR;
> +	} else {
> +		dma_addr = dma_map_page_attrs(iova->dev, page, poffset, len,
> +					      iova->dir, iova->attrs);
> +	}
> +	return dma_addr;
> +}