Re: [PATCH v5 2/2] drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Shrinker walk aborts entirely on a single unshrinkable BO, permanently wedging reclaim.
--

commit 42955bdd48d36fa90e0e98c5b4e8c6cdb3166430
Author: Shuicheng Lin <shuicheng.lin@intel.com>

drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory

This commit modifies the shrinker to take a runtime PM reference before
scanning TT memory, as shrinking non-system memory invalidates GPU mappings
which requires the device to be active. It queues a PM worker and halts the
walk if the device is suspended, and ensures the walk stops once the scan
target is met.

> diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
> index 7f40153911ffa..1bcbe764796e4 100644
> --- a/drivers/gpu/drm/xe/xe_shrinker.c
> +++ b/drivers/gpu/drm/xe/xe_shrinker.c
[ ... ]
> @@ -71,16 +73,32 @@ static s64 __xe_shrinker_walk(struct xe_device *xe,
[ ... ]
>  		ttm_bo_lru_for_each_reserved_guarded(&curs, man, &arg, ttm_bo) {
>  			if (!ttm_bo_shrink_suitable(ttm_bo, ctx))
>  				continue;
>  
>  			lret = xe_bo_shrink(ctx, ttm_bo, flags, scanned);
> -			if (lret < 0)
> -				return freed ? freed : lret;
> +			if (lret < 0) {
> +				if (!freed)
> +					freed = lret;
> +				goto out;
> +			}

[Severity: High]
This is a pre-existing issue, but does this error handling permanently wedge
memory reclaim?

If the first BO on the LRU is not purgeable during a purge pass, or is not
eviction valuable, xe_bo_shrink() returns -EBUSY. __xe_shrinker_walk() then
immediately aborts the LRU walk via this 'goto out' path (and previously via
the direct return) instead of skipping the BO and continuing the walk.

Since the unshrinkable BO is not moved to the LRU tail, subsequent shrinker
invocations will repeatedly encounter the exact same BO, abort, and return
SHRINK_STOP without making any progress. Should this continue the loop on
-EBUSY rather than aborting the entire walk?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901173059.455469-1-shuicheng.lin@intel.com?part=2