Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

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

 



On Wed, 2017-09-20 at 20:20 +0200, Daniel Vetter wrote:
> On Mon, Sep 11, 2017 at 01:06:32PM +0200, Christian König wrote:
> > Am 11.09.2017 um 12:01 schrieb Chris Wilson:
> > > [SNIP]
> > > > Yeah, but that is illegal with a fence objects.
> > > > 
> > > > When anybody allocates fences this way it breaks at least
> > > > reservation_object_get_fences_rcu(),
> > > > reservation_object_wait_timeout_rcu() and
> > > > reservation_object_test_signaled_single().
> > > 
> > > Many, many months ago I sent patches to fix them all.
> > 
> > Found those after a bit a searching. Yeah, those patches where proposed more
> > than a year ago, but never pushed upstream.
> > 
> > Not sure if we really should go this way. dma_fence objects are shared
> > between drivers and since we can't judge if it's the correct fence based on
> > a criteria in the object (only the read counter which is outside) all
> > drivers need to be correct for this.
> > 
> > I would rather go the way and change dma_fence_release() to wrap
> > fence->ops->release into call_rcu() to keep the whole RCU handling outside
> > of the individual drivers.
> 
> Hm, I entirely dropped the ball on this, I kinda assumed that we managed
> to get some agreement on this between i915 and dma_fence. Adding a pile
> more people.
> 
> Joonas, Tvrtko, I guess we need to fix this one way or the other.

I definitely didn't get the memo or notice this before. Tvrtko/Chris?

Regars, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
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