If during the freeing of an object the unbind is interrupted a system
call, which is quite possible if we have outstanding GPU writes that
must be flused, the unbind is silently aborted. This still leaves the
AGP region and backing pages allocated, and perhaps more importantly,
the object remains upon the various lists exposing us to memory
corruption.
I think this is the cause behind the use-after-free, such as
Bug 15664 - Graphics hang and kernel backtrace when starting Azureus
with Compiz enabled
https://bugzilla.kernel.org/show_bug.cgi?id=15664
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3c7c0f7..a4c0b44 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4292,6 +4292,7 @@ void i915_gem_free_object(struct drm_gem_object *obj)
{
struct drm_device *dev = obj->dev;
struct drm_i915_gem_object *obj_priv = to_intel_bo(obj);
+ int ret;
trace_i915_gem_object_destroy(obj);
@@ -4301,7 +4302,9 @@ void i915_gem_free_object(struct drm_gem_object *obj)
if (obj_priv->phys_obj)
i915_gem_detach_phys_object(dev, obj);
- i915_gem_object_unbind(obj);
+ do {
+ ret = i915_gem_object_unbind(obj);
+ } while (ret == -ERESTARTSYS);
if (obj_priv->mmap_offset)
i915_gem_free_mmap_offset(obj);
--
1.7.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
