[PATCH 1/4] sync_file: add a mutex to protect fence and callback members.

[Dave Airlie]

On 14 March 2017 at 19:30, Christian König <deathsimple at vodafone.de> wrote:
> Am 14.03.2017 um 10:29 schrieb Chris Wilson:
>>
>> On Tue, Mar 14, 2017 at 10:13:37AM +0100, Christian König wrote:
>>>
>>> Am 14.03.2017 um 09:45 schrieb Daniel Vetter:
>>>>
>>>> On Tue, Mar 14, 2017 at 10:50:51AM +1000, Dave Airlie wrote:
>>>>>
>>>>> From: Dave Airlie <airlied at redhat.com>
>>>>>
>>>>> This isn't needed currently, but to reuse sync file for Vulkan
>>>>> permanent shared semaphore semantics, we need to be able to swap
>>>>> the fence backing a sync file. This patch adds a mutex to the
>>>>> sync file and uses to protect accesses to the fence and cb members.
>>>>>
>>>>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>>>>
>>>> We've gone to pretty great lengths to rcu-protect all the fence stuff,
>>>> so
>>>> that a peek-only is entirely lockless. Can we haz the same for this pls?
>>>
>>> Yes, just wanted to suggest the same thing.
>>>
>>> Basically you just need the following to retrieve the fence:
>>>
>>> while (sync_file->fence && !(fence = fence_get_rcu(sync_file->fence));
>>
>> We even have a helper for that:
>>
>>         fence = dma_fence_get_rcu_safe(&sync_file->fence);
>>
>> (Still going to suggest using a reservation_object rather than an
>> exclusive-only implementation.)
>
>
> Yeah, thought about that as well. But the reservation object doesn't seem to
> match the required userspace semantic.
>
> E.g. you actually don't want more than one fence it in as far as I
> understand it.

I don't think a reservation object is what the vulkan semantics ask for.

Dave.