On 11/08/2013 06:28 PM, Daniel Vetter wrote:
On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> 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.
Yes. But anyway, I'll keep that get_dma_buf_unless_doomed() in local
code until someone else finds it useful.
The fs guys had issues with it as well.
Thanks,
Thomas
Cheers, Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
