From: Mikko Perttunen <mperttunen@nvidia.com>
To: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org,
Aaron Kling <webgeek1234@gmail.com>
Subject: Re: [BUG] drm/tegra: DMA buffers are not always freed
Date: Wed, 13 May 2026 12:26:03 +0900 [thread overview]
Message-ID: <I47hlmySTbquW1VgZFOofQ@nvidia.com> (raw)
In-Reply-To: <CALHNRZ9mmf_4OagcooO-s+SU1KrggT5_ZwM--ambxZKXN-oQDg@mail.gmail.com>
On Tuesday, May 12, 2026 2:29 PM Aaron Kling wrote:
> There is an issue with tegra-drm where some buffers get created, then
> freed, but the dma buffer never gets freed. Causing display controller
> memory allocations to start failing after the leaks fill up cma.
>
> I created an issue on the freedesktop issue tracker [0] with a patch
> with some debug logs I added, then a log from Android that contains
> these logs. CMA is set to 512MB, and when allocations start to fail,
> the unfreed allocations add up to just shy of 500MB, where it's
> reasonable to expect that 8MB contiguous is no longer available. The
> log was generated on a Jetson TX2 NX, but I have seen this leak on
> other archs as well, this also does not appear to be limited to soc's
> with nvdisplay.
>
> This does not appear to be a userspace issue. The graphics allocator
> works as expected for other soc vendors. And as the logs show, the
> delete dumb buffer ioctl is called, but is not always followed by the
> dma buffer getting freed. I have also observed this issue with a
> gralloc that uses the tegra gem create and such, this is not unique to
> dumb buffers, that's just the last log I had when deciding to post the
> issue to lkml.
>
> What I primarily intend to ask here is how to further debug this
> issue. I'm not finding any direct path between the delete dumb ioctl
> handling and gem release or tegra bo free. Can someone point me to the
> pieces in the middle I'm missing, where the logic is to decide is a
> buffer should be freed?
>
> Aaron
>
> [0] https://gitlab.freedesktop.org/drm/tegra/-/work_items/9
>
If the issue is specific to buffers that get used with display, I have
an idea of what the issue is -- there is some circular reference
counting with the BO cache in the host1x driver, and that means that
BOs that end up in the cache never get released.
Let me do some testing locally and I'll send out a patch once ready.
Thanks!
Mikko
next prev parent reply other threads:[~2026-05-13 3:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 5:29 [BUG] drm/tegra: DMA buffers are not always freed Aaron Kling
2026-05-13 3:26 ` Mikko Perttunen [this message]
2026-05-13 4:26 ` Aaron Kling
2026-05-15 2:39 ` Mikko Perttunen
2026-05-15 4:30 ` Aaron Kling
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=I47hlmySTbquW1VgZFOofQ@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-tegra@vger.kernel.org \
--cc=webgeek1234@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.