>
> uabi semantics question: Should we wake up everyone when the fence gets
> replaced? What's the khr semaphore expectation here?
There are no real semantics for this case, you either wait the semaphore and
replace it with NULL, or signal it where you replace the fence with a new fence.
Nobody should be using the sync_fence interfaces to poll on these fence fds.
So not crashing for non-vulkan behaviour is what we need.
The spec doesn't know anything other than this is an opaque fd,
it shouldn't be doing operations on it, execpt importing it.
>> static int sync_file_set_fence(struct sync_file *sync_file,
>> struct dma_fence **fences, int num_fences)
>> {
>> @@ -292,8 +328,10 @@ static void sync_file_free(struct kref *kref)
>> struct sync_file *sync_file = container_of(kref, struct sync_file,
>> kref);
>>
>> - if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
>> - dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
>> + if (sync_file->fence) {
>> + if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
>> + dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
>> + }
>> dma_fence_put(sync_file->fence);
>> kfree(sync_file);
>> }
>
> I think you've missed _poll, won't that oops now?
I don't think it will, all the stuff do inside the poll handler is
protected by the mutex
or do you think we should hook the new fence if the old fence has poll enabled?
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
