Quoting Sean Paul (2017-06-29 18:22:10)
> On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> > The sync_pt were not adding themselves atomically to the timeline lists,
> > corruption imminent. Only a single list is required to track the
> > unsignaled sync_pt, so reduce it and rename the lock more appropriately
> > along with using idiomatic names to distinguish a list from links along
> > it.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx>
> > Cc: Sean Paul <seanpaul@xxxxxxxxxxxx>
> > Cc: Gustavo Padovan <gustavo@xxxxxxxxxxx>
> > ---
> > drivers/dma-buf/sw_sync.c | 39 ++++++++++++++-------------------------
> > drivers/dma-buf/sync_debug.c | 9 ++++-----
> > drivers/dma-buf/sync_debug.h | 21 ++++++++-------------
> > 3 files changed, 26 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> > index 6effa1ce010e..e51fe11bbbea 100644
> > --- a/drivers/dma-buf/sw_sync.c
> > +++ b/drivers/dma-buf/sw_sync.c
> > @@ -96,9 +96,8 @@ static struct sync_timeline *sync_timeline_create(const char *name)
> > obj->context = dma_fence_context_alloc(1);
> > strlcpy(obj->name, name, sizeof(obj->name));
> >
> > - INIT_LIST_HEAD(&obj->child_list_head);
> > - INIT_LIST_HEAD(&obj->active_list_head);
> > - spin_lock_init(&obj->child_list_lock);
> > + INIT_LIST_HEAD(&obj->pt_list);
> > + spin_lock_init(&obj->lock);
> >
> > sync_timeline_debug_add(obj);
> >
> > @@ -139,17 +138,15 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
> >
> > trace_sync_timeline(obj);
> >
> > - spin_lock_irq(&obj->child_list_lock);
> > + spin_lock_irq(&obj->lock);
> >
> > obj->value += inc;
> >
> > - list_for_each_entry_safe(pt, next, &obj->active_list_head,
> > - active_list) {
> > + list_for_each_entry_safe(pt, next, &obj->pt_list, link)
> > if (dma_fence_is_signaled_locked(&pt->base))
> > - list_del_init(&pt->active_list);
> > - }
> > + list_del_init(&pt->link);
> >
> > - spin_unlock_irq(&obj->child_list_lock);
> > + spin_unlock_irq(&obj->lock);
> > }
> >
> > /**
> > @@ -171,15 +168,15 @@ static struct sync_pt *sync_pt_create(struct sync_timeline *obj,
> > if (!pt)
> > return NULL;
> >
> > - spin_lock_irq(&obj->child_list_lock);
> > -
> > sync_timeline_get(obj);
> > - dma_fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
> > + dma_fence_init(&pt->base, &timeline_fence_ops, &obj->lock,
> > obj->context, value);
> > - list_add_tail(&pt->child_list, &obj->child_list_head);
> > - INIT_LIST_HEAD(&pt->active_list);
> > + INIT_LIST_HEAD(&pt->link);
> >
> > - spin_unlock_irq(&obj->child_list_lock);
> > + spin_lock_irq(&obj->lock);
> > + if (!dma_fence_is_signaled_locked(&pt->base))
> > + list_add_tail(&pt->link, &obj->pt_list);
> > + spin_unlock_irq(&obj->lock);
> >
> > return pt;
> > }
> > @@ -204,9 +201,8 @@ static void timeline_fence_release(struct dma_fence *fence)
> >
> > spin_lock_irqsave(fence->lock, flags);
> >
> > - list_del(&pt->child_list);
> > - if (!list_empty(&pt->active_list))
> > - list_del(&pt->active_list);
> > + if (!list_empty(&pt->link))
> > + list_del(&pt->link);
> >
> > spin_unlock_irqrestore(fence->lock, flags);
> >
> > @@ -223,13 +219,6 @@ static bool timeline_fence_signaled(struct dma_fence *fence)
> >
> > static bool timeline_fence_enable_signaling(struct dma_fence *fence)
> > {
> > - struct sync_pt *pt = dma_fence_to_sync_pt(fence);
> > - struct sync_timeline *parent = dma_fence_parent(fence);
> > -
> > - if (timeline_fence_signaled(fence))
> > - return false;
> > -
> > - list_add_tail(&pt->active_list, &parent->active_list_head);
> > return true;
>
> Shouldn't you still return false if the fence is already signaled?
Yes/no :)
In this case, it is immaterial as the only way the timeline can advance
is underneath its big lock and by signaling all the fences. So by the
time dma_fence calls fence->ops->enable_signaling under that same lock
we already know that the fence isn't signaled and can't suddenly be
signaled in the middle of the function call.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
