linux-kernel - Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

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:	Fri, 31 May 2013 22:25:39 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Lucas Stach <l.stach@...gutronix.de>
Cc:	Daniel Vetter <daniel@...ll.ch>,
	김승우 <sw0312.kim@...sung.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: [RFC][PATCH 0/2] dma-buf: add importer private data for
 reimporting

On Fri, May 31, 2013 at 06:21:09PM +0200, Lucas Stach wrote:
> Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> > > Hello Daniel,
> > > 
> > > Thanks for your comment.
> > > 
> > > On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> > > > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim <sw0312.kim@...sung.com> wrote:
> > > >> importer private data in dma-buf attachment can be used by importer to
> > > >> reimport same dma-buf.
> > > >>
> > > >> Seung-Woo Kim (2):
> > > >>   dma-buf: add importer private data to attachment
> > > >>   drm/prime: find gem object from the reimported dma-buf
> > > > 
> > > > Self-import should already work (at least with the latest refcount
> > > > fixes merged). At least the tests to check both re-import on the same
> > > > drm fd and on a different all work as expected now.
> > > 
> > > Currently, prime works well for all case including self-importing,
> > > importing, and reimporting as you describe. Just, importing dma-buf from
> > > other driver twice with different drm_fd, each import create its own gem
> > > object even two import is done for same buffer because prime_priv is in
> > > struct drm_file. This means mapping to the device is done also twice.
> > > IMHO, these duplicated creations and maps are not necessary if drm can
> > > find previous import in different prime_priv.
> > 
> > Well, that's imo a bug with the other driver. If it doesn't export
> > something really simple (e.g. contiguous memory which doesn't require any
> > mmio resources at all) it should have a cache of exported dma_buf fds so
> > that it hands out the same dma_buf every time.
> 
> I agree with the reasoning here.
> 
> Though it would be nice to have this "expected driver behavior" put down
> somewhere in the documentation. Any volunteers?

I'm not sure how much sense this makes. Imo the importer side is rather
clearly spelled out, everything else is only now shaping up. And even with
the clear interface spec we pretty much have no in-tree dma_buf user who
doesn't cut corners somewhere for one or the other reason. As long the set
of exporters is fairly limited we should be fine for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/