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

[Thomas Hellstrom <thellstrom@vmware.com>]

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
>> 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