[Intel-gfx] [PATCH] drm/i915: WARN_ON fence pin leaks

[Chris Wilson]

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 at linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
> +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