On Thu, Apr 25, 2019 at 04:48:50PM +0100, Emil Velikov wrote: > From: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> > > 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.semwal@xxxxxxxxxx> > Signed-off-by: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> I don't think this matters, but +1 on ocd. Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
