From: Matthew Brost <matthew.brost@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Matthew Schwartz" <matthew.schwartz@linux.dev>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Arvind Yadav" <arvind.yadav@intel.com>
Subject: Re: [PATCH 3/3] drm/xe/pt: prevent invalid cursor access for purged BOs
Date: Thu, 25 Jun 2026 12:42:14 -0700 [thread overview]
Message-ID: <aj2Elhx87Nqe2uEc@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260625152054.450125-8-matthew.auld@intel.com>
On Thu, Jun 25, 2026 at 04:20:58PM +0100, Matthew Auld wrote:
> During a page table walk for binding, xe_pt_stage_bind() explicitly
> skips initializing the xe_res_cursor for purged BOs, treating them
> similarly to NULL VMAs by only setting the cursor size.
>
> However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check
> if the BO was purged before attempting to walk the cursor using
> xe_res_dma() and xe_res_next(). Because the cursor was left
> uninitialized for purged BOs, this falls through and triggers
> warnings like:
>
> WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next
>
> Fix this by explicitly checking if the BO is purged in both
> xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just
> as we do for NULL VMAs, avoiding the invalid cursor accesses entirely.
>
> As a precaution, also zero-initialize the cursor in xe_pt_stage_bind()
> to ensure we don't pass garbage data into the page table walkers
> if we ever hit a similar edge case in the future.
>
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8418
> Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support")
> Assisted-by: Copilot:gemini-3.1-pro-preview
> Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Arvind Yadav <arvind.yadav@intel.com>
> ---
> drivers/gpu/drm/xe/xe_pt.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index 0959e0e88a14..b1f6a96dab2e 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -433,6 +433,7 @@ xe_pt_insert_entry(struct xe_pt_stage_bind_walk *xe_walk, struct xe_pt *parent,
> static bool xe_pt_hugepte_possible(u64 addr, u64 next, unsigned int level,
> struct xe_pt_stage_bind_walk *xe_walk)
> {
> + struct xe_bo *bo = xe_vma_bo(xe_walk->vma);
> u64 size, dma;
>
> if (level > MAX_HUGEPTE_LEVEL)
> @@ -446,8 +447,8 @@ static bool xe_pt_hugepte_possible(u64 addr, u64 next, unsigned int level,
> if (next - xe_walk->va_curs_start > xe_walk->curs->size)
> return false;
>
> - /* null VMA's do not have dma addresses */
> - if (xe_vma_is_null(xe_walk->vma))
> + /* null VMA's and purged BO's do not have dma addresses */
> + if (xe_vma_is_null(xe_walk->vma) || (bo && xe_bo_is_purged(bo)))
> return true;
>
> /* if we are clearing page table, no dma addresses*/
> @@ -468,6 +469,7 @@ static bool xe_pt_hugepte_possible(u64 addr, u64 next, unsigned int level,
> static bool
> xe_pt_scan_64K(u64 addr, u64 next, struct xe_pt_stage_bind_walk *xe_walk)
> {
> + struct xe_bo *bo = xe_vma_bo(xe_walk->vma);
> struct xe_res_cursor curs = *xe_walk->curs;
>
> if (!IS_ALIGNED(addr, SZ_64K))
> @@ -476,8 +478,8 @@ xe_pt_scan_64K(u64 addr, u64 next, struct xe_pt_stage_bind_walk *xe_walk)
> if (next > xe_walk->l0_end_addr)
> return false;
>
> - /* null VMA's do not have dma addresses */
> - if (xe_vma_is_null(xe_walk->vma))
> + /* null VMA's and purged BO's do not have dma addresses */
> + if (xe_vma_is_null(xe_walk->vma) || (bo && xe_bo_is_purged(bo)))
> return true;
>
> xe_res_next(&curs, addr - xe_walk->va_curs_start);
> @@ -708,7 +710,7 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
> {
> struct xe_device *xe = tile_to_xe(tile);
> struct xe_bo *bo = xe_vma_bo(vma);
> - struct xe_res_cursor curs;
> + struct xe_res_cursor curs = {};
> struct xe_vm *vm = xe_vma_vm(vma);
> struct xe_pt_stage_bind_walk xe_walk = {
> .base = {
> --
> 2.54.0
>
prev parent reply other threads:[~2026-06-25 19:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 15:20 [PATCH 0/3] Some fixes for purged BOs Matthew Auld
2026-06-25 15:20 ` [PATCH 1/3] drm/xe: fix NPD in bo_meminfo() Matthew Auld
2026-06-25 19:39 ` Matthew Brost
2026-06-25 15:20 ` [PATCH 2/3] drm/xe: account for dontneed in fdinfo purgeable Matthew Auld
2026-06-25 19:41 ` Matthew Brost
2026-06-25 15:20 ` [PATCH 3/3] drm/xe/pt: prevent invalid cursor access for purged BOs Matthew Auld
2026-06-25 19:42 ` Matthew Brost [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=aj2Elhx87Nqe2uEc@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=arvind.yadav@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.schwartz@linux.dev \
--cc=thomas.hellstrom@linux.intel.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.