On 1/16/2020 11:30 AM, Chris Wilson wrote:
> Quoting Brian Welty (2020-01-16 19:20:47)
>> As i915 is using drm_gem_private_object_init, it is best to
>> use the inverse function for cleanup: drm_gem_object_release.
>> This removes need for a shmem_release and phys_release.
>>
>> Signed-off-by: Brian Welty <brian.welty@xxxxxxxxx>
>> ---
>> Chris, the cleanup sequence in drm_gem_object_release() vs the replaced
>> i915 code is different, but should be okay? Light testing didn't find
>> any issues.
>
> commit 0c159ffef628fa94d0f4f9128e7f2b6f2b5e86ef
> Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Date: Wed Jul 3 19:06:01 2019 +0100
>
> drm/i915/gem: Defer obj->base.resv fini until RCU callback
>
> Since reservation_object_fini() does an immediate free, rather than
> kfree_rcu as normal, we have to delay the release until after the RCU
> grace period has elapsed (i.e. from the rcu cleanup callback) so that we
> can rely on the RCU protected access to the fences while the object is a
> zombie.
>
> i915_gem_busy_ioctl relies on having an RCU barrier to protect the
> reservation in order to avoid having to take a reference and strong
> memory barriers.
>
> v2: Order is important; only release after putting the pages!
>
> Fixes: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the object
> ")
> Testcase: igt/gem_busy/close-race
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-c
> hris@xxxxxxxxxxxxxxxxxx
>
Thanks, I didn't check the history to see this was using drm_gem_object_release in past.
But looks to be using kfree_rcu now for the free.
Are we okay now as this patch has gone in since?:
commit 96e95496b02dbf1b19a2d4ce238810572e149606
Author: Christian König <christian.koenig@xxxxxxx>
Date: Tue Aug 6 13:33:12 2019 +0200
dma-buf: fix shared fence list handling in reservation_object_copy_fences
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
