summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2014-04-07 17:01:47 -0300
committerDaniel Vetter <daniel.vetter@ffwll.ch>2014-04-09 15:03:05 +0200
commitce7ec768d61672bcc45c10dd5bc2123ba1e7091f (patch)
tree3778b0162e917622f56934869c9d3f6d9c04f137
parentf476828a74b97096967104967e41b405ef07348a (diff)
downloadop-kernel-dev-ce7ec768d61672bcc45c10dd5bc2123ba1e7091f.zip
op-kernel-dev-ce7ec768d61672bcc45c10dd5bc2123ba1e7091f.tar.gz
drm/i915: dma_buf_vunmap is presumed not to fail, don't let it
Since dma_buf_vunmap() procedes blithely on ignorant of whether the driver failed to actually unmap the backing storage for the dma-buf, we need to make a best-effort to do so. This involves not allowing ourselves to be susceptible to signals causing us to leak the storage. This should have been detectable with the current i-g-t as a misplaced signal should have left the pages pinned upon freeing the object where we have a warning in place. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-rw-r--r--drivers/gpu/drm/i915/i915_gem_dmabuf.c6
1 files changed, 1 insertions, 5 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 9bb533e..321102a 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -161,12 +161,8 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
- int ret;
-
- ret = i915_mutex_lock_interruptible(dev);
- if (ret)
- return;
+ mutex_lock(&dev->struct_mutex);
if (--obj->vmapping_count == 0) {
vunmap(obj->dma_buf_vmapping);
obj->dma_buf_vmapping = NULL;
OpenPOWER on IntegriCloud