Re: Patch "drm/xe: Fix shrinker accounting double-subtraction on nested external pins" has been added to the 7.2-stable tree

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: MADVISE on pinned FB double-subtracts shrinker pages
--

commit fd0d0cc5f1317ebe67563e2a71be658497f18472
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Subject: drm/xe: Fix shrinker accounting double-subtraction on nested external pins

This commit introduces helpers to ensure shrinker accounting is only updated
on the outermost pin and final unpin transitions. It also excludes imported
dma-bufs from pin/unpin shrinker accounting and updates the framebuffer pin
paths to use these new helpers.

Link: https://patch.msgid.link/20261002100830.12297-2-thomas.hellstrom@linux.intel.com

> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> @@ -356,7 +356,7 @@ static struct i915_vma *__xe_pin_fb_vma(struct drm_gem_object *obj, bool is_dpt,
>  		drm_exec_retry_on_contention(&exec);
>  		xe_validation_retry_on_oom(&ctx, &ret);
>  		if (!ret)
> -			ttm_bo_pin(&bo->ttm);
> +			xe_bo_pin_account(bo);

[Severity: High]
Can this new shrinker accounting for framebuffers lead to a
double-subtraction underflow?

When a user creates a BO, maps it (creating a VMA, willneed_count = 1), and
uses it as a display framebuffer, this path calls xe_bo_pin_account() which
subtracts the BO's pages from the shrinkable count. However, FB pinning does
not increment willneed_count to prevent MADVISE transitions while pinned.

If the user then invokes the DRM_IOCTL_XE_VM_MADVISE ioctl to set the BO to
DONTNEED, the willneed_count drops to 0 and xe_bo_set_purgeable_shrinker()
is called. xe_bo_set_purgeable_shrinker() will unconditionally transition
the state and subtract the pages from the shrinkable count again:

xe_bo_set_purgeable_shrinker() {
        /* Transfer pages from shrinkable to purgeable count */
        xe_shrinker_mod_pages(xe->mem.shrinker, -tt_pages, tt_pages);
}

Since the count is stored as a signed long but added to an unsigned long
total in xe_shrinker_count(), dropping below zero causes an enormous
positive value. Could this cause the kernel memory reclaimer to excessively
invoke the shrinker under memory pressure, leading to a system livelock
or severe performance degradation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026101238-calm-footing-389c@gregkh?part=1