| Message ID | 20220920170628.3391-1-nirmoy.das@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915: Do not cleanup obj with NULL bo->resource | expand |
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@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> 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? > --- > 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);
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@intel.com> > > Reviewed-by: Matthew Auld <matthew.auld@intel.com> > > 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);
Hi Matt On 9/20/2022 7:06 PM, 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 Please add the below Fixes before merging, I missed that. Fixes: ad74457a6b5a96 ("drm/i915/dgfx: Release mmap on rpm suspend") Thanks, Nirmoy > Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> > --- > 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);
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);
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@intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)