On Thu, Apr 25, 2019 at 04:48:50PM +0100, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> In dma_buf_attach() we allocate memory w/o a mutex being held, thus in
> the error path we should kfree() it after the mutex_unlock.
> 
> The inverse function dma_buf_deattach() gets this right.
> 
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

I don't think this matters, but +1 on ocd.

Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>

> ---
>  drivers/dma-buf/dma-buf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 3ae6c0c2cc02..57ddeb735b8b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -579,8 +579,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
>       return attach;
>  
>  err_attach:
> -     kfree(attach);
>       mutex_unlock(&dmabuf->lock);
> +     kfree(attach);
>       return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_attach);
> -- 
> 2.21.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to