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: <200909011543.48439.laurent.pinchart@ideasonboard.com>
Date:	Tue, 1 Sep 2009 15:43:48 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	"Russell King - ARM Linux" <linux@....linux.org.uk>
Cc:	Steven Walter <stevenrwalter@...il.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 Tuesday 01 September 2009 15:28:24 Russell King - ARM Linux wrote:
> On Tue, Aug 25, 2009 at 08:53:29AM -0400, Steven Walter wrote:
> > On Thu, Aug 6, 2009 at 6:25 PM, Russell King - ARM
> > Linux<linux@....linux.org.uk> wrote:
> > [...]
> >
> > > As far as userspace DMA coherency, the only way you could do it with
> > > current kernel APIs is by using get_user_pages(), creating a
> > > scatterlist from those, and then passing it to dma_map_sg().  While the
> > > device has ownership of the SG, userspace must _not_ touch the buffer
> > > until after DMA has completed.
> >
> > [...]
> >
> > Would that work on a processor with VIVT caches?  It seems not.  In
> > particular, dma_map_page uses page_address to get a virtual address to
> > pass to map_single().  map_single() in turn uses this address to
> > perform cache maintenance.  Since page_address() returns the kernel
> > virtual address, I don't see how any cache-lines for the userspace
> > virtual address would get invalidated (for the DMA_FROM_DEVICE case).
>
> You are correct.
>
> > If that's true, then what is the correct way to allow DMA to/from a
> > userspace buffer with a VIVT cache?  If not true, what am I missing?
>
> I don't think you read what I said (but I've also forgotten what I did
> say).
>
> To put it simply, the kernel does not support DMA direct from userspace
> pages.  Solutions which have been proposed in the past only work with a
> sub-set of conditions (such as the one above only works with VIPT
> caches.)

I might be missing something obvious, but I fail to see how VIVT caches could 
work at all with multiple mappings. If a kernel-allocated buffer is DMA'ed to, 
we certainly want to invalidate all cache lines that store buffer data. As the 
cache doesn't care about physical addresses we thus need to invalidate all 
virtual mappings for the buffer. If the buffer is mmap'ed in userspace I don't 
see how that would be done.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ