On Tue, Apr 04, 2017 at 12:52:32PM +0100, Chris Wilson wrote:
> On Tue, Apr 04, 2017 at 02:27:30PM +1000, Dave Airlie wrote:
> > +struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
> > + struct dma_fence *fence)
> > +{
> > + struct dma_fence *ret_fence = NULL;
> > +
> > + if (sync_file->type != SYNC_FILE_TYPE_SEMAPHORE)
> > + return NULL;
> > +
> > + if (fence)
> > + dma_fence_get(fence);
> > +
> > + mutex_lock(&sync_file->lock);
> > +
> > + ret_fence = sync_file_get_fence_locked(sync_file);
> > + if (ret_fence) {
> > + if (test_bit(POLL_ENABLED, &ret_fence->flags))
> > + dma_fence_remove_callback(ret_fence, &sync_file->cb);
>
> This is racy with sync_file_poll. And sync_file_poll now needs rcu
> protection (as does all access to sync_file->fence), I need to check
> whether the previous patches are complete. Also needs to handle, or
> forbid, the caller passing in the same fence.
Race is serialised by sync_file_poll also be under the mutex, so that's
ok. Just the possibility of being passed in its own fence.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
