Quoting Jason Ekstrand (2017-08-10 01:31:52)
> On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Quoting Jason Ekstrand (2017-08-08 23:46:02)
> > The atomic exchange operation we were doing before in replace_fence was
> > sufficient for the case where it raced with itself. However, if you
> > have a race between a replace_fence and dma_fence_get(syncobj->fence),
> > you may end up with the entire replace_fence happening between the point
> > in time where the one thread gets the syncobj->fence pointer and when it
> > calls dma_fence_get() on it. If this happens, then the reference may be
> > dropped before we get a chance to get a new one.
> This doesn't require a spinlock, just dma_fence_get_rcu_safe(). The
> argument for keeping this patch lies in the merit of later patches..
> Doesn't that also require that we start using an RCU for syncobj? That was my
> interpretation of the hieroglyphics above the definition of get_rcu_safe()
Interesting you mention RCUing syncobj... The spinlock in
drm_syncobj_find() is the first contention point we hit. If we do make
syncobj RCU'ed we can avoid that lock.
dri-devel mailing list