linux-kernel - RE: [PATCH 00/14] DMA-mapping framework redesign preparation

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]

Date:	Tue, 27 Dec 2011 17:53:13 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Marek Szyprowski <m.szyprowski@...sung.com>
Cc:	'Matthew Wilcox' <matthew@....cx>, linux-kernel@...r.kernel.org,
	'Benjamin Herrenschmidt' <benh@...nel.crashing.org>,
	'Thomas Gleixner' <tglx@...utronix.de>,
	'Andrew Morton' <akpm@...ux-foundation.org>,
	'Arnd Bergmann' <arnd@...db.de>,
	'Stephen Rothwell' <sfr@...b.auug.org.au>,
	microblaze-uclinux@...e.uq.edu.au, linux-arch@...r.kernel.org,
	x86@...nel.org, linux-sh@...r.kernel.org,
	linux-alpha@...r.kernel.org, sparclinux@...r.kernel.org,
	linux-ia64@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	linux-mips@...ux-mips.org, discuss@...-64.org,
	linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
	linaro-mm-sig@...ts.linaro.org, 'Jonathan Corbet' <corbet@....net>,
	'Kyungmin Park' <kyungmin.park@...sung.com>,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
Subject: RE: [PATCH 00/14] DMA-mapping framework redesign preparation

On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote:
[...]
> > > Usually these drivers don't touch the buffer data at all, so the mapping
> > > in kernel virtual address space is not needed. We can introduce
> > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore
> > > creation of kernel virtual mapping. This way we can save previous
> > > vmalloc area and simply some mapping operation on a few architectures.
> > 
> > I really think this wants to be a separate function.  dma_alloc_coherent
> > is for allocating memory to be shared between the kernel and a driver;
> > we already have dma_map_sg for mapping userspace I/O as an alternative
> > interface.  This feels like it's something different again rather than
> > an option to dma_alloc_coherent.
> 
> That is just a starting point for the discussion. 
> 
> I thought about this API a bit and came to conclusion that there is no much
> difference between a dma_alloc_coherent which creates a mapping in kernel
> virtual space and the one that does not. It is just a hint from the driver
> that it will not use that mapping at all. Of course this attribute makes sense
> only together with adding a dma_mmap_attrs() call, because otherwise drivers
> won't be able to get access to the buffer data.

This depends.  On Virtually indexed systems like PA-RISC, there are two
ways of making a DMA range coherent.  One is to make the range uncached.
This is incredibly slow and not what we do by default, but it can be
used to make multiple mappings coherent.  The other is to load the
virtual address up as a coherence index into the IOMMU.  This makes it a
full peer in the coherence process, but means we can only designate a
single virtual range to be coherent (not multiple mappings unless they
happen to be congruent).  Perhaps it doesn't matter that much, since I
don't see a use for this on PA, but if any other architecture works the
same, you'd have to designate a single mapping as the coherent one and
essentially promise not to use the other mapping if we followed our
normal coherence protocols.

Obviously, the usual range we currently make coherent is the kernel
mapping (that's actually the only virtual address we have by the time
we're deep in the iommu code), so designating a different virtual
address would need some surgery to the guts of the iommu code.

James


--
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/