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

From: Gustavo Padovan
Date: Tue Jul 12 2016 - 09:44:15 EST


2016-07-12 Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>:

> Op 11-07-16 om 22:27 schreef Gustavo Padovan:
> > 2016-07-10 Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>:
> >
> >> Op 08-07-16 om 17:44 schreef Gustavo Padovan:
> >>> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
> >>>
> >>> 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@xxxxxxxxxxxxxxx>
> >>> ---
> >>> 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.

Move the callback removal to sync_file_free() seems a good idea to me.
I'll rework this patch taking in account your suggestions and resend it.

Gustavo