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
