linux-kernel - Re: [PATCH v1 5/9] sparc64: Use physical address DMA mapping

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: <20251003151603.GD3360665@nvidia.com>
Date: Fri, 3 Oct 2025 12:16:03 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
	Leon Romanovsky <leonro@...dia.com>,
	Andreas Larsson <andreas@...sler.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"David S. Miller" <davem@...emloft.net>,
	Geoff Levand <geoff@...radead.org>, Helge Deller <deller@....de>,
	Ingo Molnar <mingo@...hat.com>, iommu@...ts.linux.dev,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	Jason Wang <jasowang@...hat.com>, Juergen Gross <jgross@...e.com>,
	linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Matt Turner <mattst88@...il.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Richard Henderson <richard.henderson@...aro.org>,
	sparclinux@...r.kernel.org,
	Stefano Stabellini <sstabellini@...nel.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	virtualization@...ts.linux.dev, x86@...nel.org,
	xen-devel@...ts.xenproject.org, Magnus Lindholm <linmag7@...il.com>
Subject: Re: [PATCH v1 5/9] sparc64: Use physical address DMA mapping

On Sun, Sep 28, 2025 at 06:02:25PM +0300, Leon Romanovsky wrote:
> @@ -273,13 +272,16 @@ static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
>  	u32 bus_addr, ret;
>  	unsigned long iopte_protection;
>  
> +	if (attrs & DMA_ATTR_MMIO)
> +		goto bad_no_ctx;
> +
>  	iommu = dev->archdata.iommu;
>  	strbuf = dev->archdata.stc;
>  
>  	if (unlikely(direction == DMA_NONE))
>  		goto bad_no_ctx;
>  
> -	oaddr = (unsigned long)(page_address(page) + offset);
> +	oaddr = (unsigned long)(phys_to_virt(phys));
>  	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
>  	npages >>= IO_PAGE_SHIFT;

This should be cleaned up some more:

	oaddr = (unsigned long)(page_address(page) + offset);
	ret = bus_addr | (oaddr & ~IO_PAGE_MASK);

	base_paddr = __pa(oaddr & IO_PAGE_MASK);

Makes no sense to phys_to_virt() then __pa() on that result. Drop oaddr.

Then I would copy and paste the comment from mips about DMA_ATTR_MMIO
> @@ -367,13 +366,16 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
>  	dma_addr_t bus_addr, ret;
>  	long entry;
>  
> +	if (attrs & DMA_ATTR_MMIO)
> +		goto bad;
> +
>  	iommu = dev->archdata.iommu;
>  	atu = iommu->atu;
>  
>  	if (unlikely(direction == DMA_NONE))
>  		goto bad;
>  
> -	oaddr = (unsigned long)(page_address(page) + offset);
> +	oaddr = (unsigned long)(phys_to_virt(phys));
>  	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
>  	npages >>= IO_PAGE_SHIFT;

Same remarks here

> +static dma_addr_t iounit_map_phys(struct device *dev, phys_addr_t phys,
> +		size_t len, enum dma_data_direction dir, unsigned long attrs)
>  {
> -	void *vaddr = page_address(page) + offset;
> +	void *vaddr = phys_to_virt(phys);
>  	struct iounit_struct *iounit = dev->archdata.iommu;
>  	unsigned long ret, flags;

iounit_get_area() does not seem to need vaddr:

        npages = ((vaddr & ~PAGE_MASK) + size + (PAGE_SIZE-1)) >> PAGE_SHIFT;

~PAGE_MASK is page_offset()

	iopte = MKIOPTE(__pa(vaddr & PAGE_MASK));

__pa(phys_to_virt(pa)) again:
  iopte = MKIOPTE(PAGE_ALIGN(pa));

	vaddr = IOUNIT_DMA_BASE + (scan << PAGE_SHIFT) + (vaddr & ~PAGE_MASK);

page_offset, then it replaces vaddr.

So I'd tidy this too.

> @@ -202,10 +204,10 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
>	 * We expect unmapped highmem pages to be not in the cache.
>  	 * XXX Is this a good assumption?
>  	 * XXX What if someone else unmaps it here and races us?
>  	 */

At least ARM32 has code that seems to say these assumptions are not
always true.. Oh well.

Jason