linux-kernel - Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma

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:	Thu, 21 Apr 2016 11:35:12 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Stephen Boyd <stephen.boyd@...aro.org>
Cc:	linux-kernel@...r.kernel.org, Laura Abbott <lauraa@...eaurora.org>,
	linux-arm@...ts.infradead.org, Robin Murphy <robin.murphy@....com>,
	Laura Abbott <labbott@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mark Brown <broonie@...nel.org>,
	Will Deacon <will.deacon@....com>,
	Ming Lei <ming.lei@...onical.com>
Subject: Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs

Hi Stephen,

On Tue, Apr 19, 2016 at 06:04:27PM -0700, Stephen Boyd wrote:
> From: Laura Abbott <lauraa@...eaurora.org>
> 
> Some systems are memory constrained but they need to load very
> large firmwares. The firmware subsystem allows drivers to request
> this firmware be loaded from the filesystem, but this requires
> that the entire firmware be loaded into kernel memory first
> before it's provided to the driver. This can lead to a situation
> where we map the firmware twice, once to load the firmware into
> kernel memory and once to copy the firmware into the final
> resting place.
> 
> This design creates needless memory pressure and delays loading
> because we have to copy from kernel memory to somewhere else.
> Let's add a couple DMA APIs that allow us to map DMA buffers into
> the CPU's address space in arbitrary sizes. With this API, we can
> allocate a DMA buffer with DMA_ATTR_NO_KERNEL_MAPPING and move a
> small mapping window across our large DMA buffer to load the
> firmware directly into buffer.

The first two patches in this series don't make sense to me. I don't
understand what the memory pressure is: physical or virtual? Because
they don't seem to address the former (the DMA buffer is allocated in
full) while the latter doesn't need any addressing at all on arm64, we
have plenty of VA space.

Why do you even need the coherent DMA API? Can you use the streaming API
(map_sg etc.) with a separately allocated buffer?

-- 
Catalin