All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Guard pages being reaped by OOM whilst binding-to-GTT
Date: Tue, 20 Nov 2012 10:48:54 +0100	[thread overview]
Message-ID: <20121120094854.GE5854@phenom.ffwll.local> (raw)
In-Reply-To: <1352451530-10767-1-git-send-email-chris@chris-wilson.co.uk>

On Fri, Nov 09, 2012 at 08:58:50AM +0000, Chris Wilson wrote:
> In the circumstances that the shrinker is allowed to steal the mutex
> in order to reap pages, we need to be careful to prevent it operating on
> the current object and shooting ourselves in the foot.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Ok, I this is definitely the major one that I've thought of, but I think
I've found another place that need a similar treatment:

i915_gem_fault: In between bind_to_gtt and vm_insert_pfn we have a call to
get_fence, which might potentially call kmalloc due to a pending request.
I know, it's highly unlikely that this will ever matter, but I think if we
braket this with a pin/unpin, it will nicely serve as a reminder where to
reserve/unreserve and object, in case we ever switch to a per-object
locking scheme.

Otherwise I can't poke holes into this any more ...

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 159dca5..f225583 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3091,6 +3091,8 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
>  	if (ret)
>  		return ret;
>  
> +	i915_gem_object_pin_pages(obj);
> +
>   search_free:
>  	if (map_and_fenceable)
>  		free_space =
> @@ -3121,14 +3123,17 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
>  					       obj->cache_level,
>  					       map_and_fenceable,
>  					       nonblocking);
> -		if (ret)
> +		if (ret) {
> +			i915_gem_object_unpin_pages(obj);
>  			return ret;
> +		}
>  
>  		goto search_free;
>  	}
>  	if (WARN_ON(!i915_gem_valid_gtt_space(dev,
>  					      obj->gtt_space,
>  					      obj->cache_level))) {
> +		i915_gem_object_unpin_pages(obj);
>  		drm_mm_put_block(obj->gtt_space);
>  		obj->gtt_space = NULL;
>  		return -EINVAL;
> @@ -3137,6 +3142,7 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
>  
>  	ret = i915_gem_gtt_prepare_object(obj);
>  	if (ret) {
> +		i915_gem_object_unpin_pages(obj);
>  		drm_mm_put_block(obj->gtt_space);
>  		obj->gtt_space = NULL;
>  		return ret;
> @@ -3159,6 +3165,7 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
>  
>  	obj->map_and_fenceable = mappable && fenceable;
>  
> +	i915_gem_object_unpin_pages(obj);
>  	trace_i915_gem_object_bind(obj, map_and_fenceable);
>  	i915_gem_verify_gtt(dev);
>  	return 0;
> -- 
> 1.7.10.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2012-11-20  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10 11:07 [PATCH] drm/i915: Wait for the mutex whilst the reaper runs Chris Wilson
2012-10-10 15:08 ` [PATCH] drm/i915: Borrow our struct_mutex for the direct reclaim Chris Wilson
2012-10-10 21:02   ` Daniel Vetter
2012-11-08 13:49   ` Ben Widawsky
2012-11-09  8:58     ` [PATCH] drm/i915: Guard pages being reaped by OOM whilst binding-to-GTT Chris Wilson
2012-11-20  9:48       ` Daniel Vetter [this message]
2012-10-10 15:21 ` [PATCH] drm/i915: Wait for the mutex whilst the reaper runs Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121120094854.GE5854@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.