Re: [PATCH] dma-buf/sync_file: only enable fence signalling during wait

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Op 11-07-16 om 22:27 schreef Gustavo Padovan:
> 2016-07-10 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
>
>> Op 08-07-16 om 17:44 schreef Gustavo Padovan:
>>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>>
>>> Signalling doesn't need to be enabled at sync_file creation, it is only
>>> required if userspace waiting the fence to signal through poll().
>>>
>>> Thus we delay fence_add_callback() until poll is called. It only adds the
>>> callback the first time poll() is called. This avoid re-adding the same
>>> callback multiple times.
>>>
>>> v2: rebase and update to work with new fence support for sync_file
>>>
>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>> ---
>>> This patch applies on top of my latest sync_file changes to support
>>> fence_array: https://lkml.org/lkml/2016/7/4/534
>>>
>>>  drivers/dma-buf/sync_file.c | 23 ++++++++++++++---------
>>>  include/linux/sync_file.h   |  2 ++
>>>  2 files changed, 16 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
>>> index 61a687c..1db4a64 100644
>>> --- a/drivers/dma-buf/sync_file.c
>>> +++ b/drivers/dma-buf/sync_file.c
>>> @@ -86,8 +86,6 @@ struct sync_file *sync_file_create(struct fence *fence)
>>>  		 fence->ops->get_timeline_name(fence), fence->context,
>>>  		 fence->seqno);
>>>  
>>> -	fence_add_callback(fence, &sync_file->cb, fence_check_cb_func);
>>> -
>>>  	return sync_file;
>>>  }
>>>  EXPORT_SYMBOL(sync_file_create);
>>> @@ -269,9 +267,6 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
>>>  		goto err;
>>>  	}
>>>  
>>> -	fence_add_callback(sync_file->fence, &sync_file->cb,
>>> -			   fence_check_cb_func);
>>> -
>>>  	strlcpy(sync_file->name, name, sizeof(sync_file->name));
>>>  	return sync_file;
>>>  
>>> @@ -286,7 +281,6 @@ static void sync_file_free(struct kref *kref)
>>>  	struct sync_file *sync_file = container_of(kref, struct sync_file,
>>>  						     kref);
>>>  
>>> -	fence_remove_callback(sync_file->fence, &sync_file->cb);
>>>  	fence_put(sync_file->fence);
>>>  	kfree(sync_file);
>>>  }
>>> @@ -306,13 +300,24 @@ static unsigned int sync_file_poll(struct file *file, poll_table *wait)
>>>  
>>>  	poll_wait(file, &sync_file->wq, wait);
>>>  
>>> +	if (!sync_file->enabled) {
>>> +		fence_add_callback(sync_file->fence, &sync_file->cb,
>>> +				   fence_check_cb_func);
>>> +		sync_file->enabled = true;
>>> +	}
>> Won't this blow up completely with 2 threads polling at the same time?
> Indeed, using atomic operations on enabled should fix this.
No, it still would blow up without locking around fence_remove/add_callback too..

Personally I would just add the callback once, then remove it in destructor.

Something like:

poll:
if (!atomic_xchg(&sync_file->enabled, 1)) {
if (fence_add_callback(...) < 0)
wake up sync_file->wq, fence is signaled
}

sync_file_free:
if (atomic_read(&sync_file->enabled))
fence_remove_callback(...);

fence_put()

It's not like fence can disable hw signaling when all callbacks are removed anyway,
it's harmless to keep it on the list.

~Maarten