Re: [PATCH v4 1/4] drm/xe: Don't abort the shrinker walk on -EBUSY

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] xe: loop termination check bypassed on -EBUSY causing unbounded shrinker scan
--

commit a9661e97694161cd803806ccc4ad309e99a9f298
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>

drm/xe: Don't abort the shrinker walk on -EBUSY

xe_bo_shrink() returns -EBUSY for bos that can't currently be shrunk.
The shrinker LRU walk treated any negative return value as fatal and
aborted. This commit changes it to skip bos for which xe_bo_shrink()
returns -EBUSY and continues the walk.

> diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
> index deb4378c1ec15..4e4da76936f49 100644
> --- a/drivers/gpu/drm/xe/xe_shrinker.c
> +++ b/drivers/gpu/drm/xe/xe_shrinker.c
> @@ -113,6 +113,9 @@ static int __xe_shrinker_walk(struct xe_shrinker *shrinker,
>  				continue;
>  
>  			lret = xe_bo_shrink(ctx, ttm_bo, flags, scanned);
> +			/* Like the TTM LRU walk, skip bos we can't shrink now. */
> +			if (lret == -EBUSY)
> +				continue;

[Severity: Medium]
Does this continue statement inadvertently bypass the loop termination check?

In xe_bo_shrink(), the scanned counter is incremented before potentially
returning -EBUSY:

xe_bo_shrink() {
	...
	*scanned += tt->num_pages;
	lret = ttm_bo_shrink(ctx, bo, ...);
	...
	return lret;
}

If a sequence of buffer objects return -EBUSY from ttm_bo_shrink(), could
this introduce a regression where the shrinker performs an unbounded scan
over the list because the *scanned >= to_scan check at the bottom of the
loop body is bypassed?

>  			if (lret < 0) {
>  				ret = lret;
>  				goto out;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016133523.3622-1-thomas.hellstrom@linux.intel.com?part=1