All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "WenTao Liang" <vulab@iscas.ac.cn>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/tegra: fix host1x_bo_pin leak in tegra_dc_pin error path
Date: Sun, 28 Jun 2026 15:11:39 +0000	[thread overview]
Message-ID: <20260628151140.0C81C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260628150228.47948-1-vulab@iscas.ac.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Resource leak (BO references and map objects) in pin_job error paths.
--

commit 385c1315fdf5345a4727ff1380f8b72577ca3566
Author: WenTao Liang <vulab@iscas.ac.cn>

    drm/tegra: fix host1x_bo_pin leak in tegra_dc_pin error path
    
    When map->chunks > 1 triggers an error, the function jumps to unpin
    before storing the current map in state->map[i]. The unpin loop only
    cleans up previously pinned planes (indices 0 through i-1), so the
    current mapping returned by host1x_bo_pin is never released via
    host1x_bo_unpin.
    
    Suggested-by: Greg KH <gregkh@linuxfoundation.org>
    Fixes: c6aeaf56f468 ("drm/tegra: Implement correct DMA-BUF semantics")
    Cc: stable@vger.kernel.org

> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
> index ffe5f06b770dc..e0b146a0926e7 100644
> --- a/drivers/gpu/drm/tegra/plane.c
> +++ b/drivers/gpu/drm/tegra/plane.c
> @@ -161,6 +161,7 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct tegra_plane_state *state)
>  			 */
>  			if (map->chunks > 1) {
>  				err = -EINVAL;
> +				host1x_bo_unpin(map);
>  				goto unpin;
>  			}
>  

[Severity: High]
This is a pre-existing issue, but the exact same resource leak pattern exists
in drivers/gpu/host1x/job.c:pin_job().

If host1x_bo_pin() fails, or if map->chunks > 1, the function jumps to the
unpin label:

drivers/gpu/host1x/job.c:pin_job() {
    ...
		reloc->target.bo = host1x_bo_get(reloc->target.bo);
		...
		bo = reloc->target.bo;
		...
		map = host1x_bo_pin(dev, bo, direction, NULL);
		if (IS_ERR(map)) {
			err = PTR_ERR(map);
			goto unpin;
		}

		/* ... */
		if (map->chunks > 1) {
			err = -EINVAL;
			goto unpin;
		}
    ...
}

Because the acquired bo and map have not yet been added to the job->unpins
array, host1x_job_unpin() will not clean them up. This leaks the bo reference
if host1x_bo_pin() fails, and leaks both the bo reference and the map if
map->chunks > 1.

Similarly, later in the same function during gather BO processing, if the IOVA
allocation fails:

drivers/gpu/host1x/job.c:pin_job() {
    ...
			alloc = alloc_iova(&host->iova, gather_size >> shift,
					   host->iova_end >> shift, true);
			if (!alloc) {
				err = -ENOMEM;
				goto put;
			}
    ...
}

Jumping to put releases g->bo, but leaks the already created map because it
was not added to job->unpins.

Could similar cleanup logic be added to the error paths in pin_job() to
prevent these memory leaks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628150228.47948-1-vulab@iscas.ac.cn?part=1

  reply	other threads:[~2026-06-28 15:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-28 15:02 [PATCH v2] drm/tegra: fix host1x_bo_pin leak in tegra_dc_pin error path WenTao Liang
2026-06-28 15:11 ` sashiko-bot [this message]
2026-06-29  5:59 ` Mikko Perttunen
2026-06-30  9:19   ` Greg KH

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=20260628151140.0C81C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vulab@iscas.ac.cn \
    /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.