All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Deborah Brouwer" <deborah.brouwer@collabora.com>
Cc: dri-devel@lists.freedesktop.org, ojeda@kernel.org
Subject: Re: [PATCH v10 5/7] drm/tyr: add a kernel buffer object
Date: Tue, 28 Jul 2026 18:54:19 +0000	[thread overview]
Message-ID: <20260728185419.E7BC21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728-fw-boot-b4-v10-5-9187aefa3f2f@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Resource leak: `KernelBo::drop` permanently leaks the GEM buffer object and its virtual mapping if `vm.unmap_range()` fails.
--

--- Patch [5]: [PATCH v10 5/7] drm/tyr: add a kernel buffer object ---
commit f17ba69672f18401371cf98a1da7881e0b938c23
Author: Deborah Brouwer <deborah.brouwer@collabora.com>

drm/tyr: add a kernel buffer object

This commit introduces a buffer object type (KernelBo) for internal driver
allocations managed by the kernel. It wraps a GEM shmem object and automatically
handles GPU virtual address space mapping during creation and unmapping on drop.

> diff --git a/drivers/gpu/drm/tyr/gem.rs b/drivers/gpu/drm/tyr/gem.rs
> index c28be61a01bb2..69e1c75e59a55 100644
> --- a/drivers/gpu/drm/tyr/gem.rs
> +++ b/drivers/gpu/drm/tyr/gem.rs

[ ... ]

> +impl Drop for KernelBo<'_> {
> +    fn drop(&mut self) {
> +        let va = self.va_range.start;
> +        let size = self.va_range.end - self.va_range.start;
> +
> +        if let Err(e) = self.vm.unmap_range(va, size) {

[Severity: Medium]
Does this leak the GEM buffer object if unmap_range() fails?

If unmap_range() encounters an error (such as a kmalloc failure due to
memory pressure when preallocating GPUVA objects to handle a mapping split),
it aborts the unmap operation. 

Because the error is caught and ignored here, the drm_gpuvm will retain its
reference to the GEM object indefinitely, leaking it along with its
physical pages.

> +            // If unmap_range fails, it is still safe to drop the
> +            // KernelBo and its ARef to the GEM buffer object because
> +            // GPUVM also holds a reference to the GEM buffer object.
> +            // The physical pages won't be freed or reallocated.
> +            dev_err!(
> +                self.vm.dev(),
> +                "Failed to unmap KernelBo range {:#x}..{:#x}: {:?}",
> +                self.va_range.start,
> +                self.va_range.end,
> +                e
> +            );
> +        }
> +    }
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728-fw-boot-b4-v10-0-9187aefa3f2f@collabora.com?part=5

  reply	other threads:[~2026-07-28 18:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28 18:39 [PATCH v10 0/7] drm/tyr: firmware loading and MCU boot support Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 1/7] drm/tyr: add resources to RegistrationData Deborah Brouwer
2026-07-28 18:55   ` sashiko-bot
2026-07-28 18:39 ` [PATCH v10 2/7] drm/tyr: add a generic slot manager Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 3/7] drm/tyr: add Memory Management Unit (MMU) support Deborah Brouwer
2026-07-28 18:52   ` sashiko-bot
2026-07-28 19:31   ` Danilo Krummrich
2026-07-28 20:35     ` Deborah Brouwer
2026-07-28 21:19       ` Danilo Krummrich
2026-07-28 18:39 ` [PATCH v10 4/7] drm/tyr: add GPU virtual memory (VM) support Deborah Brouwer
2026-07-28 18:54   ` sashiko-bot
2026-07-28 18:39 ` [PATCH v10 5/7] drm/tyr: add a kernel buffer object Deborah Brouwer
2026-07-28 18:54   ` sashiko-bot [this message]
2026-07-28 18:39 ` [PATCH v10 6/7] drm/tyr: add parser for firmware binary Deborah Brouwer
2026-07-28 18:47   ` sashiko-bot
2026-07-28 18:39 ` [PATCH v10 7/7] drm/tyr: add Microcontroller Unit (MCU) booting Deborah Brouwer

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=20260728185419.E7BC21F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=deborah.brouwer@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.