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, stable@vger.kernel.org,
	Daniel Vetter <daniel.vetter@fwll.ch>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Invalidate the relocation presumed_offsets along the slow path
Date: Wed, 16 Jan 2013 10:53:48 +0100	[thread overview]
Message-ID: <20130116095348.GC8347@phenom.ffwll.local> (raw)
In-Reply-To: <1358266674-28308-1-git-send-email-chris@chris-wilson.co.uk>

On Tue, Jan 15, 2013 at 04:17:54PM +0000, Chris Wilson wrote:
> In the slow path, we are forced to copy the relocations prior to
> acquiring the struct mutex in order to handle pagefaults. We forgo
> copying the new offsets back into the relocation entries in order to
> prevent a recursive locking bug should we trigger a pagefault whilst
> holding the mutex for the reservations of the execbuffer. Therefore, we
> need to reset the presumed_offsets just in case the objects are rebound
> back into their old locations after relocating for this exexbuffer - if
> that were to happen we would assume the relocations were valid and leave
> the actual pointers to the kernels dangling, instant hang.
> 
> Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Sun Nov 21 22:07:12 2010 +0000
> 
>     drm/i915: Handle pagefaults in execbuffer user relocations
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@fwll.ch>
> Cc: stable@vger.kernel.org

Picked up for -fixes, thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 4532757..40c062d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -767,6 +767,8 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
>  	total = 0;
>  	for (i = 0; i < count; i++) {
>  		struct drm_i915_gem_relocation_entry __user *user_relocs;
> +		u64 invalid_offset = (u64)-1;
> +		int j;
>  
>  		user_relocs = (void __user *)(uintptr_t)exec[i].relocs_ptr;
>  
> @@ -777,6 +779,25 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
>  			goto err;
>  		}
>  
> +		/* As we do not update the known relocation offsets after
> +		 * relocating (due to the complexities in lock handling),
> +		 * we need to mark them as invalid now so that we force the
> +		 * relocation processing next time. Just in case the target
> +		 * object is evicted and then rebound into its old
> +		 * presumed_offset before the next execbuffer - if that
> +		 * happened we would make the mistake of assuming that the
> +		 * relocations were valid.
> +		 */
> +		for (j = 0; j < exec[i].relocation_count; j++) {
> +			if (copy_to_user(&user_relocs[j].presumed_offset,
> +					 &invalid_offset,
> +					 sizeof(invalid_offset))) {
> +				ret = -EFAULT;
> +				mutex_lock(&dev->struct_mutex);
> +				goto err;
> +			}
> +		}
> +
>  		reloc_offset[i] = total;
>  		total += exec[i].relocation_count;
>  	}
> -- 
> 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

      parent reply	other threads:[~2013-01-16  9:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15 16:17 [PATCH] drm/i915: Invalidate the relocation presumed_offsets along the slow path Chris Wilson
2013-01-15 18:21 ` [Intel-gfx] " Daniel Vetter
2013-01-15 18:28   ` Chris Wilson
2013-01-16  9:53 ` Daniel Vetter [this message]

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=20130116095348.GC8347@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@fwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.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.