On Mon, Oct 17, 2016 at 4:25 AM, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> 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. BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
