[kernel/f18] drm/i915: Invalidate the relocation presumed_offsets along the slow path

Justin M. Forbes jforbes at fedoraproject.org
Tue Jan 22 23:36:26 UTC 2013


commit d483733654fa663cd710f8b43218672573f3add9
Author: Justin M. Forbes <jforbes at redhat.com>
Date:   Tue Jan 22 17:30:40 2013 -0600

    drm/i915: Invalidate the relocation presumed_offsets along the slow path

 ...ocation-presumed_offsets-along-slow-patch.patch |   67 ++++++++++++++++++++
 kernel.spec                                        |   11 +++-
 2 files changed, 77 insertions(+), 1 deletions(-)
---
diff --git a/drm-invalidate-relocation-presumed_offsets-along-slow-patch.patch b/drm-invalidate-relocation-presumed_offsets-along-slow-patch.patch
new file mode 100644
index 0000000..be557dc
--- /dev/null
+++ b/drm-invalidate-relocation-presumed_offsets-along-slow-patch.patch
@@ -0,0 +1,67 @@
+commit 262b6d363fcff16359c93bd58c297f961f6e6273
+Author: Chris Wilson <chris at chris-wilson.co.uk>
+Date:   Tue Jan 15 16:17:54 2013 +0000
+
+    drm/i915: Invalidate the relocation presumed_offsets along the slow path
+    
+    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 at 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 at chris-wilson.co.uk>
+    Cc: Daniel Vetter <daniel.vetter at fwll.ch>
+    Cc: stable at vger.kernel.org
+    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
+
+diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+index d6a994a..26d08bb 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;
+ 	}
diff --git a/kernel.spec b/kernel.spec
index 0049b32..6b649bb 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -62,7 +62,7 @@ Summary: The Linux kernel
 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 202
+%global baserelease 203
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -783,6 +783,9 @@ Patch21234: iwlegacy-fix-IBSS-cleanup.patch
 #rhbz 902523
 Patch21236: libata-replace-sata_settings-with-devslp_timing.patch
 
+# i915 hang fixes
+Patch21237: drm-invalidate-relocation-presumed_offsets-along-slow-patch.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -1496,6 +1499,9 @@ ApplyPatch iwlegacy-fix-IBSS-cleanup.patch
 #rhbz 902523
 ApplyPatch libata-replace-sata_settings-with-devslp_timing.patch
 
+#i915
+ApplyPatch drm-invalidate-relocation-presumed_offsets-along-slow-patch.patch
+
 # END OF PATCH APPLICATIONS
 
 %endif
@@ -2352,6 +2358,9 @@ fi
 #                 ||----w |
 #                 ||     ||
 %changelog
+* Tue Jan 22 2013 Justin M. Forbes <jforbes at redhat.com> - 3.7.4-203
+- Add i915 bugfix from airlied
+
 * Tue Jan 22 2013 Peter Robinson <pbrobinson at fedoraproject.org>
 - Apply ARM errata fix
 - disable HVC_DCC and VIRTIO_CONSOLE on ARM


More information about the scm-commits mailing list