Quoting Ville Syrjala (2021-02-09 02:19:18) > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Let's scream if we are about to release a frontbuffer which > is still in use. > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
