Message ID | 20210209021918.16234-3-ville.syrjala@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling | expand |
Quoting Ville Syrjala (2021-02-09 02:19:18) > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Let's scream if we are about to release a frontbuffer which > is still in use. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/display/intel_frontbuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c > index 7b38eee9980f..6fc6965b6133 100644 > --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c > +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c > @@ -224,6 +224,8 @@ static void frontbuffer_release(struct kref *ref) > struct drm_i915_gem_object *obj = front->obj; > struct i915_vma *vma; > > + drm_WARN_ON(obj->base.dev, atomic_read(&front->bits)); I had to double check the meaning of bits, and indeed they are cleared by intel_frontbuffer_track as the scanout is switched away from the object. A stacktrace here isn't particularly useful for tracking down the leak, but it is a trivial method to make CI pay attention. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c index 7b38eee9980f..6fc6965b6133 100644 --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c @@ -224,6 +224,8 @@ static void frontbuffer_release(struct kref *ref) struct drm_i915_gem_object *obj = front->obj; struct i915_vma *vma; + drm_WARN_ON(obj->base.dev, atomic_read(&front->bits)); + spin_lock(&obj->vma.lock); for_each_ggtt_vma(vma, obj) { i915_vma_clear_scanout(vma);