linux-kernel - Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")

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:	Tue, 8 Sep 2009 09:05:14 -0400
From:	Steven Walter <stevenrwalter@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Imre Deak <imre.deak@...ia.com>,
	ext Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	David Xiao <dxiao@...adcom.com>,
	Ben Dooks <ben-linux@...ff.org>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Robin Holt <holt@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	v4l2_linux <linux-media@...r.kernel.org>,
	"linux-arm-kernel@...ts.arm.linux.org.uk" 
	<linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is 
	get_user_pages() enough to prevent pages from being swapped out ?")

On Thu, Sep 3, 2009 at 4:36 AM, Russell King - ARM
Linux<linux@....linux.org.uk> wrote:
> On Wed, Sep 02, 2009 at 06:10:44PM +0300, Imre Deak wrote:
>> To my understanding buffers returned by dma_alloc_*, kmalloc, vmalloc
>> are ok:
>
> For dma_map_*, the only pages/addresses which are valid to pass are
> those returned by get_free_pages() or kmalloc.  Everything else is
> not permitted.
>
> Use of vmalloc'd and dma_alloc_* pages with the dma_map_* APIs is invalid
> use of the DMA API.  See the notes in the DMA-mapping.txt document
> against "dma_map_single".

Actually, DMA-mapping.txt seems to explicitly say that it's allowed to
use pages allocated by vmalloc:

"It is possible to DMA to the _underlying_ memory mapped into a
vmalloc() area, but this requires walking page tables to get the
physical addresses, and then translating each of those pages back to a
kernel address using something like __va()."

>> For user mappings I think you'd have to do an additional flush for
>> the direct mapping, while the user mapping is flushed in dma_map_*.
>
> I will not accept a patch which adds flushing of anything other than
> the kernel direct mapping in the dma_map_* functions, so please find
> a different approach.

What's the concern here?  Just the performance overhead of the checks
and additional flushes?  It seems much more desirable for the
dma_map_* API to take care of potential cache aliases than to require
every driver to manage it for itself.  After all, part of the purpose
of the DMA API is to manage the cache maintenance around DMAs in an
architecture-independent way.
-- 
-Steven Walter <stevenrwalter@...il.com>
--
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/