[Linaro-mm-sig] [PATCH RFC] dma-buf/fs Add get_[file|dma_buf]_unless_doomed

Daniel Vetter daniel.vetter at ffwll.ch
Fri Nov 8 09:28:39 PST 2013


On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> This, however comes with two implications
> 1) Once a DMA-buf is added, it stays alive at least until someone removes
> the gem name of the exporting object, regardless whether there are any
> external users or not. I think this is OK, but unnecessary.

Imo that's actually fairly nice guarantee, since if you have dumb
userspace that always re-does the export/import dance accross a device
the importer can check whether it has the same object already
somewhere.

Without this guarantee we'll end up mapping the same underlying
storage multiple times. btw this is the part where userspace can still
trick the kernel. I have testcases for it, but thus far lacked the
time to implement the fix. It needs a combination of nasty+dumb
userspace though to be a real issue.

> 2) If someone decides to get a new handle from fd, and the gem name has
> already been removed, a new gem name is created for the exporting dma-buf by
> the requested client. This is why I can't do the same. Because of the
> relaxed RCU locking, I can't re-add a name to a TTM base object. Removing it
> is always part of the object destruction sequence.

Yeah, we seem to have a bit a split in how gem handles userspace
handles and the weak references they cause and how ttm does it. ttm
uses kref_get_unless_zero for weak references. Atm gem objects
themselves still need the big mutex, but the only blocker is the mmap
code (actually the has table). My plan (somewhere on my todo list) is
to do the same trick for that weak reference from the mmap offset
lookup structure.

Anyway I just wanted to point out with my original mail that this
problem can be solved in different ways. But I see that the weak ref
approach with a possibly failing get call suits the current ttm design
(and so I guess vmwgfx) a bit better.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list