From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: Charan Teja Reddy <charante@codeaurora.org>,
sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
vinmenon@codeaurora.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] dma-buf: WARN on dmabuf release with pending attachments
Date: Fri, 23 Jul 2021 17:01:16 +0200 [thread overview]
Message-ID: <YPrZvM8BI7VO8xQk@phenom.ffwll.local> (raw)
In-Reply-To: <b057b0fe-75ae-d872-f500-a307543d8233@amd.com>
On Fri, Jul 23, 2021 at 02:34:13PM +0200, Christian König wrote:
> Am 23.07.21 um 14:31 schrieb Charan Teja Reddy:
> > It is expected from the clients to follow the below steps on an imported
> > dmabuf fd:
> > a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd
> > b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf
> > o Here the kernel does some slab allocations, say for
> > dma_buf_attachment and may be some other slab allocation in the
> > dmabuf->ops->attach().
> > c) Client may need to do dma_buf_map_attachment().
> > d) Accordingly dma_buf_unmap_attachment() should be called.
> > e) dma_buf_detach () // Clients detach to the dmabuf.
> > o Here the slab allocations made in b) are freed.
> > f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last
> > reference.
> >
> > Now say an erroneous client failed at step c) above thus it directly
> > called dma_buf_put(), step f) above. Considering that it may be the last
> > reference to the dmabuf, buffer will be freed with pending attachments
> > left to the dmabuf which can show up as the 'memory leak'. This should
> > at least be reported as the WARN().
> >
> > Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
>
> Good idea. I would expect a crash immediately, but from such a backtrace it
> is quite hard to tell what the problem is.
>
> Patch is Reviewed-by: Christian König <christian.koenig@amd.com> and I'm
> going to push this to drm-misc-next on Monday if nobody objects.
The boom only happens a lot later when the offending import uses the
attachment again. This here has a good chance to catch that early
drm_buf_put(), so I think it's a good improvement. We'll still Oops later
on ofc, but meh.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Thanks,
> Christian.
>
> > ---
> > drivers/dma-buf/dma-buf.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 511fe0d..733c8b1 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry)
> > if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
> > dma_resv_fini(dmabuf->resv);
> > + WARN_ON(!list_empty(&dmabuf->attachments));
> > module_put(dmabuf->owner);
> > kfree(dmabuf->name);
> > kfree(dmabuf);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
prev parent reply other threads:[~2021-07-23 15:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 12:31 [PATCH] dma-buf: WARN on dmabuf release with pending attachments Charan Teja Reddy
2021-07-23 12:34 ` Christian König
2021-07-23 15:01 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YPrZvM8BI7VO8xQk@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=charante@codeaurora.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=vinmenon@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).