Am 14.08.19 um 22:07 schrieb Daniel Vetter: > On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote: >> Quoting Chris Wilson (2019-08-14 19:24:01) >>> This reverts >>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper") >>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper") >>> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence") >>> 5d344f58da76 ("dma-buf: nuke reservation_object seq number") > Oh I didn't realize they landed already. > >>> The scenario that defeats simply grabbing a set of shared/exclusive >>> fences and using them blissfully under RCU is that any of those fences >>> may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this >>> scenario, while keeping the rcu_read_lock we need to establish that no >>> fence was changed in the dma_resv after a read (or full) memory barrier. > So if I'm reading correctly what Chris is saying here I guess my half > comment in that other thread pointed at a real oversight. Since I still > haven't checked and it's too late for real review not more for now. Yeah, the root of the problem is that I didn't realized that fences could be reused while in the RCU grace period. Need to go a step back and try to come up with a complete new approach for synchronization. >>> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >>> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> I said I needed to go lie down, that proves it. > Yeah I guess we need to wait for Christian to wake up an have a working > brain. Well in that case you will need to wait for a few more years for my kids to enter school age :) Cheers, Christian. > -Daniel > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx