Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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()

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux