From: sashiko-bot@kernel.org
To: "Honglei Huang" <honglei1.huang@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/5] drm/xe: have xe_svm_range embed one drm_gpusvm_pages
Date: Wed, 17 Jun 2026 10:56:36 +0000 [thread overview]
Message-ID: <20260617105636.73D4B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260617103602.1491609-4-honglei1.huang@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Device memory mappings are leaked in the error path of drm_gpusvm_get_pages() because device_unmap is skipped.
--
commit 25e4cbe499297aaf84b70f35d35aa1d25e43829b
Author: Honglei Huang <honghuan@amd.com>
drm/xe: have xe_svm_range embed one drm_gpusvm_pages
With drm_gpusvm_pages now self contained, make xe stop relying
on the drm_gpusvm_range pages and take responsibility for the page
lifecycle on the driver side.
> diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> index d6407c94cdda3..7af535853c380 100644
> --- a/drivers/gpu/drm/drm_gpusvm.c
> +++ b/drivers/gpu/drm/drm_gpusvm.c
[ ... ]
> @@ -1245,8 +1248,6 @@ void drm_gpusvm_range_remove(struct drm_gpusvm *gpusvm,
> return;
>
> drm_gpusvm_notifier_lock(gpusvm);
> - __drm_gpusvm_unmap_pages(gpusvm, &range->pages, npages);
> - __drm_gpusvm_free_pages(gpusvm, &range->pages);
[Severity: High]
This isn't a bug introduced by this patch, but does the error path in
drm_gpusvm_get_pages() leak device memory mappings?
In drm_gpusvm_get_pages(), if a device page is successfully mapped via
dpagemap->ops->device_map(), but a subsequent page mapping fails, the code
jumps to the err_unmap label and calls __drm_gpusvm_unmap_pages() to clean up:
err_unmap:
svm_pages->flags.has_dma_mapping = true;
__drm_gpusvm_unmap_pages(gpusvm, svm_pages, num_dma_mapped);
Inside __drm_gpusvm_unmap_pages(), the loop uses the dpagemap loaded from
svm_pages->dpagemap to resolve the callback:
else if (dpagemap && dpagemap->ops->device_unmap)
dpagemap->ops->device_unmap(dpagemap,
dev, addr);
Since svm_pages->dpagemap isn't updated until the end of drm_gpusvm_get_pages()
upon complete success, it remains NULL (or holds a stale reference) during
err_unmap. Will this evaluate to false and skip the required device_unmap
operations for the newly mapped device pages?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617103602.1491609-1-honglei1.huang@amd.com?part=3
next prev parent reply other threads:[~2026-06-17 10:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 10:35 [PATCH v2 0/5] drm/gpusvm: split MM and device state across gpusvm/range/pages Honglei Huang
2026-06-17 10:35 ` [PATCH v2 1/5] drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flags Honglei Huang
2026-06-17 10:50 ` sashiko-bot
2026-06-17 13:54 ` Matthew Brost
2026-06-17 10:35 ` [PATCH v2 2/5] drm/gpusvm: embed struct drm_device into drm_gpusvm_pages Honglei Huang
2026-06-17 10:49 ` sashiko-bot
2026-06-17 10:36 ` [PATCH v2 3/5] drm/xe: have xe_svm_range embed one drm_gpusvm_pages Honglei Huang
2026-06-17 10:56 ` sashiko-bot [this message]
2026-06-17 10:36 ` [PATCH v2 4/5] drm/gpusvm: move struct drm_gpusvm_pages out of struct drm_gpusvm_range Honglei Huang
2026-06-17 10:52 ` sashiko-bot
2026-06-17 10:36 ` [PATCH v2 5/5] drm/gpusvm: let the drm_gpusvm core context purely MM level Honglei Huang
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=20260617105636.73D4B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=honglei1.huang@amd.com \
--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.