On Tue, May 13, 2014 at 10:55:40AM +0200, Daniel Vetter wrote: > The fence pin count should always be <= the bo pin count. If that's > not the case then we have a funny problem and are leaking references > somewhere. > > Which means we can catch fence pin leaks by checking for the same > upper limit as we do for the bo pin count. Inspired by a discussion > with Ville about a fence leak igt testcase. > > v2: Also check for fence->pin_count <= ggtt_vma->pin_count, since that > might catch a leak even quicker. Also de-inline them, they're getting > too big. > > Cc: Ville Syrjälä <[email protected]> > Signed-off-by: Daniel Vetter <[email protected]> > --- > +bool > +i915_gem_object_pin_fence(struct drm_i915_gem_object *obj) > +{ > + if (obj->fence_reg != I915_FENCE_REG_NONE) { > + struct drm_i915_private *dev_priv = obj->base.dev->dev_private; > + struct i915_vma *ggtt_vma = i915_gem_obj_to_ggtt(obj); > + > + WARN_ON(!ggtt_vma || > + dev_priv->fence_regs[obj->fence_reg].pin_count > > + ggtt_vma->pin_count);
Just do the first check as that supersedes the second. As a stricter test, pass in i915_vma from the caller so that we can assert that we only ever pin a fence when binding to the GGTT. That's only a marginal nuisance for intel_pin_and_fence_fb_obj(). > + WARN_ON(dev_priv->fence_regs[obj->fence_reg].pin_count == > + DRM_I915_GEM_OBJECT_MAX_PIN_COUNT); > + dev_priv->fence_regs[obj->fence_reg].pin_count++; > + return true; > + } else > + return false; > +} -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
