summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_gem_execbuffer.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2013-02-20 08:26:06 +0100
committerJens Axboe <axboe@kernel.dk>2013-02-20 08:26:06 +0100
commitd4308febf3551d46884561b7c3fdd62ad3ca7ff2 (patch)
treeb8c48122df7c36761c6fb5d70647a09605892b9f /drivers/gpu/drm/i915/i915_gem_execbuffer.c
parentc206c70924737db6836382c09ad2dacd04bb6204 (diff)
parent087ffecdaa1875cc683a7a5bc0695b3ebfce3bad (diff)
Merge branch 'stable/for-jens-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-3.9/drivers
Konrad writes: Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.9 which has bug-fixes that did not make it in v3.8. They all are marked as material for the stable tree as well. There are two bug-fixes for the code that has been in there for some time (that is the Jan's fix and one of mine). And there are two bug-fixes for the persistent grant feature that debuted in v3.8 for xen blk[back|front]end.
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem_execbuffer.c')
-rw-r--r--drivers/gpu/drm/i915/i915_gem_execbuffer.c21
1 files changed, 21 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d6a994a0739..26d08bb5821 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -539,6 +539,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;
@@ -549,6 +551,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;
}