[PATCH 2/4] dma-buf: stop using the dmabuf->lock so much
Daniel Vetter
daniel at ffwll.ch
Tue Oct 22 10:13:47 UTC 2019
On Mon, Oct 21, 2019 at 01:15:22PM +0200, Christian König wrote:
> The attachment list is now protected by the dma_resv object.
> So we can drop holding this lock to allow concurrent attach
> and detach operations.
>
> Signed-off-by: Christian König <christian.koenig at amd.com>
> ---
> drivers/dma-buf/dma-buf.c | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 753be84b5fd6..c736e67ae1a1 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,8 +685,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> attach->dmabuf = dmabuf;
> attach->dynamic_mapping = dynamic_mapping;
>
> - mutex_lock(&dmabuf->lock);
> -
> if (dmabuf->ops->attach) {
> ret = dmabuf->ops->attach(dmabuf, attach);
> if (ret)
> @@ -696,8 +694,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> list_add(&attach->node, &dmabuf->attachments);
> dma_resv_unlock(dmabuf->resv);
>
> - mutex_unlock(&dmabuf->lock);
This changes the rules, now ->attach/->detach and the list manipulation
aren't done under the same lock anymore. I don't think this matters, but
imo good to mention in the commit message.
> -
> /* When either the importer or the exporter can't handle dynamic
> * mappings we cache the mapping here to avoid issues with the
> * reservation object lock.
> @@ -726,7 +722,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>
> err_attach:
> kfree(attach);
> - mutex_unlock(&dmabuf->lock);
> return ERR_PTR(ret);
>
> err_unlock:
> @@ -776,14 +771,12 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> dma_resv_unlock(attach->dmabuf->resv);
> }
>
> - mutex_lock(&dmabuf->lock);
> dma_resv_lock(dmabuf->resv, NULL);
> list_del(&attach->node);
> dma_resv_unlock(dmabuf->resv);
> if (dmabuf->ops->detach)
> dmabuf->ops->detach(dmabuf, attach);
>
> - mutex_unlock(&dmabuf->lock);
> kfree(attach);
> }
> EXPORT_SYMBOL_GPL(dma_buf_detach);
> @@ -1247,14 +1240,6 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
> "size", "flags", "mode", "count", "ino");
>
> list_for_each_entry(buf_obj, &db_list.head, list_node) {
> - ret = mutex_lock_interruptible(&buf_obj->lock);
> -
> - if (ret) {
> - seq_puts(s,
> - "\tERROR locking buffer object: skipping\n");
> - continue;
> - }
> -
This will mildly conflict with the revised version of patch 1 (since the
dma_resv_lock needs to be here).
With both nits addressed:
Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
> buf_obj->size,
> buf_obj->file->f_flags, buf_obj->file->f_mode,
> @@ -1307,7 +1292,6 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>
> count++;
> size += buf_obj->size;
> - mutex_unlock(&buf_obj->lock);
> }
>
> seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list