[RFC] dma-buf/fence: avoid holding lock while calling cb

[Christian König]

Am 17.10.2016 um 20:02 schrieb Rob Clark:
> On Mon, Oct 17, 2016 at 4:25 AM, Maarten Lankhorst
> <maarten.lankhorst at linux.intel.com> wrote:
>> Op 16-10-16 om 18:03 schreef Rob Clark:
>>> Currently with fence-array, we have a potential deadlock situation.  If we
>>> fence_add_callback() on an array-fence, the array-fence's lock is aquired
>>> first, and in it's ->enable_signaling() callback, it will install cb's on
>>> it's array-member fences, so the array-member's lock is acquired second.
>>>
>>> But in the signal path, the array-member's lock is acquired first, and the
>>> array-fence's lock acquired second.
>>>
>>> One approach to deal with this is avoid holding the fence's lock when
>>> calling the cb.  It is a bit intrusive and I haven't fixed up all the
>>> other drivers that call directly or indirectly fence_signal_locked().
>>>
>>> I guess the other option would be introduce a work-queue for array-fence?
>>> Or??
>> Enable signaling when creating the fence array is an option. As an optimization we don't enable
>> signaling when creating a single fence, but when you merge fences you're probably interested
>> in the result anyway.
> I think what you mean is to fence_add_callback() on all the member
> fences up-front, rather from ops->enable_signaling()?  I guess that
> should work.

Yeah, but we should try to avoid that. Enabling signaling all the time 
is really expensive for some use cases.

I would certainly prefer the approach using a work item.

Regards,
Christian.

>
> BR,
> -R
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel