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
