linux-kernel - Re: [PATCH v7 16/16] ARM: LPAE: Add the Kconfig entries

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] [day] [month] [year] [list]

Date:	Wed, 2 Nov 2011 18:07:58 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 16/16] ARM: LPAE: Add the Kconfig entries

On Wed, Nov 02, 2011 at 05:21:42PM +0000, Russell King - ARM Linux wrote:
> On Wed, Aug 10, 2011 at 04:03:39PM +0100, Catalin Marinas wrote:
> > +config ARCH_DMA_ADDR_T_64BIT
> > +	def_bool ARM_LPAE
> > +
> 
> I think this should be selected only when we have a DMA engine supporting
> 64-bit addresses.  Technically LPAE itself doesn't give us that assurance.
> 
> If you have this kind of a setup:
> 
> CPU <==++==> RAM
>        ||
>      IOMMU
>        |
>    DMA device
> 
> where == and || means >32-bit addressing, and | means 32-bit addressing.

That's one configuration but there are other configurations with PCI
devices that can access 64-bit addresses without requiring an IOMMU.

> In such a setup, having dma_addr_t be 64-bit is pointless because it
> should never see 64-bit addresses (the DMA API should deal with the
> IOMMU and provide a list of DMA addresses to be placed into RAM for
> the DMA device which takes account of the mappings setup in the IOMMU.)
> 
> So, I think 64-bit dma_addr_t should be a property of the DMA devices
> present in the system rather than whether the CPUs MMU can deal with
> >32-bit addresses or not.

I agree, that's a property of the device but it doesn't mean that we
can't have a dma_addr_t as u64.

The current DMA allocator uses pages that can be placed anywhere if the
mask is 0xffffffff, so just making this type u32 does not change such
allocation, just ignoring the top bits of the bus address. What I think
we need for this case is GFP_DMA32, assuming that ZONE_DMA32 is set up:

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e4e7f6c..a51026b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -81,6 +81,8 @@ static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t gf
 
 	if (mask < 0xffffffffULL)
 		gfp |= GFP_DMA;
+	else if (mask == 0xffffffffULL)
+		gfp |= GFP_DMA32;
 
 	page = alloc_pages(gfp, order);
 	if (!page)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/