All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: <sashiko-reviews@lists.linux.dev>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [RFC 3/4] drm/xe: Bump prefetch BO LRU via GPUSVM devmem callback
Date: Fri, 18 Sep 2026 14:02:36 -0700	[thread overview]
Message-ID: <aq2m7LRrjAXw9pyC@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260916113633.087841F00893@smtp.kernel.org>

On Wed, Sep 16, 2026 at 11:36:32AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] drm/xe: type confusion in xe_svm_devmem_lru_bump() due to unverified cast
> --
> 
> commit 09484da3688fb659e04396330f11c6ca63c00b90
> Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> 
> drm/xe: Bump prefetch BO LRU via GPUSVM devmem callback
> 
> This commit adds xe_svm_devmem_lru_bump() and sets it as the
> drm_gpusvm_ctx.devmem_fn callback in the prefetch worker to move backing
> BOs to the LRU tail during get_pages.
> 
> > diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> > index 6c3033fc4db73..7de6ed818d45e 100644
> > --- a/drivers/gpu/drm/xe/xe_svm.c
> > +++ b/drivers/gpu/drm/xe/xe_svm.c
> 
> [ ... ]
> 
> > @@ -1612,6 +1613,25 @@ int xe_svm_range_get_pages(struct xe_vm *vm, struct xe_svm_range *range,
> >  	return err;
> >  }
> >  
> > +/**
> > + * xe_svm_devmem_lru_bump() - Move a range's backing BO to the TTM LRU tail
> > + * @devmem_allocation: The device-memory allocation backing the range's pages
> > + *
> > + * Intended as a &drm_gpusvm_ctx.devmem_fn. Runs under the GPUSVM notifier lock;
> > + * the dma-resv trylock avoids inverting against eviction/shrinker, which take
> > + * dma-resv before the notifier lock. A contended BO is simply skipped.
> > + */
> > +void xe_svm_devmem_lru_bump(struct drm_pagemap_devmem *devmem_allocation)
> > +{
> > +	struct xe_bo *bo = to_xe_bo(devmem_allocation);

Based on Sashiko feedback - we probably want a check here...

if (devmem_allocation->ops != &dpagemap_devmem_ops)
	return;

This would future-proof us if we ever start using SVM with device memory
sharing on non-Xe devices while still sharing the same
device_private_page_owner. At that point, we would likely need to
rethink the LRU bumping, perhaps via a dpagemap_devmem_ops vfunc, but we
would not immediately explode.

Matt

> > +
> > +	if (!dma_resv_trylock(bo->ttm.base.resv))
> 
> [Severity: High]
> Does this cast safely handle generic device memory allocations?
> 
> If userspace maps device memory from another DRM driver into the SVM address
> space, hmm_range_fault() can return those foreign device pages. The drm_gpusvm
> core will then loop over them in drm_gpusvm_walk_devmem() and invoke this
> callback with the foreign driver's devmem_allocation.
> 
> Since the generic struct drm_pagemap_devmem * is cast to a driver-specific
> struct xe_bo * without verifying that the allocation actually belongs to the
> xe driver, can this lead to a type confusion and invalid pointer dereference
> on bo->ttm.base.resv?
> 
> Unprivileged users mapping memory from multiple devices in the same process
> could trigger a GPU fault or prefetch, making this a potential denial of
> service vector.
> 
> > +		return;
> > +
> > +	ttm_bo_move_to_lru_tail_unlocked(&bo->ttm);
> > +	dma_resv_unlock(bo->ttm.base.resv);
> > +}
> > +
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260916112828.2528881-6-himal.prasad.ghimiray@intel.com?part=3

  reply	other threads:[~2026-09-18 21:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 11:28 [RFC 0/4] Refresh TTM LRU on SVM prefetch Himal Prasad Ghimiray
2026-09-16 11:28 ` [RFC 1/4] drm/pagemap: Add helper to access backing devmem allocation Himal Prasad Ghimiray
2026-09-18 21:04   ` Matthew Brost
2026-09-16 11:28 ` [RFC 2/4] drm/gpusvm: Add devmem callback to get_pages Himal Prasad Ghimiray
2026-09-16 11:36   ` sashiko-bot
2026-09-18 21:24     ` Matthew Brost
2026-09-21  8:34       ` Ghimiray, Himal Prasad
2026-09-16 11:28 ` [RFC 3/4] drm/xe: Bump prefetch BO LRU via GPUSVM devmem callback Himal Prasad Ghimiray
2026-09-16 11:36   ` sashiko-bot
2026-09-18 21:02     ` Matthew Brost [this message]
2026-09-21  8:35       ` Ghimiray, Himal Prasad
2026-09-16 11:28 ` [RFC 4/4] drm/xe: Bump prefetch BO LRU for already-valid ranges Himal Prasad Ghimiray
2026-09-16 11:33   ` sashiko-bot
2026-09-18 21:28     ` Matthew Brost
2026-09-21  8:35       ` Ghimiray, Himal Prasad
2026-09-16 11:32 ` ✗ CI.KUnit: failure for Refresh TTM LRU on SVM prefetch Patchwork

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=aq2m7LRrjAXw9pyC@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.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.