linux-kernel - Re: [Linaro-mm-sig] [PATCH] [RFC] dma-buf: mmap support

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

Message-ID: <20120321222528.GA20712@phenom.ffwll.local>
Date:	Wed, 21 Mar 2012 23:25:28 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Rebecca Schultz Zavin <rebecca@...roid.com>
Cc:	Rob Clark <rob.clark@...aro.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	linaro-mm-sig@...ts.linaro.org,
	LKML <linux-kernel@...r.kernel.org>,
	DRI Development <dri-devel@...ts.freedesktop.org>,
	linux-media@...r.kernel.org
Subject: Re: [Linaro-mm-sig] [PATCH] [RFC] dma-buf: mmap support

On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
> I want to make sure I understand how this would work.  I've been planning
> on making cache maintenance implicit, and most of the corresponding
> userspace components I've seen for android expect to do implicit cache
> maintenance on these buffers if they need cached mappings.  The android
> framework has a logical place for this maintenance to take place.  I assume
> that you'd detect a buffer leaving the cpu domain by using the
> dma_data_direction passed to dma_buf_map_attachment?  We're definitely
> pushing a bunch of complexity into the exporter, that at least on android
> could easily be covered by an explicit api.  I'm not dead set against it, I
> just want to make sure I get it right if we go down this road.

Hm, you're talking about implicit cache management, which I read as: The
kernel does some magic so that userspace doesn't have to care. But I guess
you mean what I'd call explicit cache management, where userspace tells
the kernel which ranges to invalidate/flush?

The idea is that the exporter would invalidate cpu caches at fault time.
And when a dma-device wants to read from it (using the direction argument
of dma_buf_map_attachement) it would shoot down the mappings, flush caches
and then allow the dma op to happen. Note that this is obvously only
required if the mapping is not coherent (uc/wc on arm).

I agree that for cached mappings this will suck, but to get dma-buf of the
ground I prefer a simpler interface at the beginning, which could get
extended later on. The issue is that I expect that a few importers simply
can't hanlde cache management with explicit flush/invalidate ioctl calls
from userspace and we hence need coherently-looking mappings anyway.

Imo the best way to enable cached mappings is to later on extend dma-buf
(as soon as we have some actual exporters/importers in the mainline
kernel) with an optional cached_mmap interface which requires explict
prepare_mmap_access/finish_mmap_acces calls. Then if both exporter and
importer support this, it could get used - otherwise the dma-buf layer
could transparently fall back to coherent mappings.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
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/