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ä <ville.syrjala@xxxxxxxxxxxxxxx>
> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> ---
> +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
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
