Commit 6b607e3a authored by Daniel Vetter's avatar Daniel Vetter Committed by Sumit Semwal

dma-buf: don't hold the mutex around map/unmap calls

The mutex protects the attachment list and hence needs to be held
around the callbakc to the exporters (optional) attach/detach
functions.

Holding the mutex around the map/unmap calls doesn't protect any
dma_buf state. Exporters need to properly protect any of their own
state anyway (to protect against calls from their own interfaces).
So this only makes the locking messier (and lockdep easier to anger).

Therefore let's just drop this.

v2: Rebased on top of latest dma-buf-next git.
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarRob Clark <rob.clark@linaro.org>
Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
parent f9a24d1a
......@@ -258,9 +258,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
mutex_lock(&attach->dmabuf->lock);
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
mutex_unlock(&attach->dmabuf->lock);
return sg_table;
}
......@@ -282,10 +280,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
mutex_lock(&attach->dmabuf->lock);
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
direction);
mutex_unlock(&attach->dmabuf->lock);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
......@@ -88,7 +88,7 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
/* mutex to serialize list manipulation and other ops */
/* mutex to serialize list manipulation and attach/detach */
struct mutex lock;
void *priv;
};
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment