From 6b607e3a658fee490bdabfdeb739a3eb498b1bff Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 19 Mar 2012 00:34:25 +0100 Subject: 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: Daniel Vetter Reviewed-by: Rob Clark Signed-off-by: Sumit Semwal --- drivers/base/dma-buf.c | 5 ----- 1 file changed, 5 deletions(-) (limited to 'drivers/base/dma-buf.c') diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 3c8c0232ce43..5641b9c8d50c 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -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); -- cgit v1.2.3