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
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
