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.we...@intel.com>
> ---
> 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 <ch...@chris-wilson.co.uk>
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 <ch...@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.a...@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-c
h...@chris-wilson.co.uk
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
