Am 20.09.22 um 19:13 schrieb Matthew Auld:
On 20/09/2022 18:06, Nirmoy Das wrote:
For delayed BO release i915_ttm_delete_mem_notify()
gets called twice, once with proper bo->resource and
another time with NULL. We shouldn't do anything for
the 2nd time as we already cleanedup the obj once.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850
Signed-off-by: Nirmoy Das <nirmoy.das@xxxxxxxxx>
Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx>
Christian, as per above it looks like ttm calls into the
delete_mem_notify() hook twice if the object ends up on the delayed
destroy list, is that expected/normal?
Yeah, that's expected. IIRC some driver depended on this for some reason.
I already wanted to change this behavior, but forgot to do so after the
patch set which made bo->resource a pointer landed.
Going to look into it once more.
Thanks,
Christian.
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0544b0a4a43a..e3fc38dd5db0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -511,7 +511,7 @@ static void i915_ttm_delete_mem_notify(struct
ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
intel_wakeref_t wakeref = 0;
- if (likely(obj)) {
+ if (bo->resource && likely(obj)) {
/* ttm_bo_release() already has dma_resv_lock */
if (i915_ttm_cpu_maps_iomem(bo->resource))
wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
