提交 eb91626a 编写于 作者: D Daniel Vetter 提交者: Dave Airlie

drm/i915: unpin backing storage in dmabuf_unmap

This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.

v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Armin K. <krejzi@email.com> (v1)
Tested-by: NDave Airlie <airlied@redhat.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>
上级 d2b2c084
...@@ -85,9 +85,17 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment, ...@@ -85,9 +85,17 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *sg, struct sg_table *sg,
enum dma_data_direction dir) enum dma_data_direction dir)
{ {
struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
mutex_lock(&obj->base.dev->struct_mutex);
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir); dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg); sg_free_table(sg);
kfree(sg); kfree(sg);
i915_gem_object_unpin_pages(obj);
mutex_unlock(&obj->base.dev->struct_mutex);
} }
static void i915_gem_dmabuf_release(struct dma_buf *dma_buf) static void i915_gem_dmabuf_release(struct dma_buf *dma_buf)
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册