On 11/08/2013 06:28 PM, Daniel Vetter wrote:
On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom thellstrom@vmware.com wrote:
This, however comes with two implications
- 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.
- 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