From: sashiko-bot@kernel.org
To: "FNU VISHWANATHA" <fnu.vishwanatha@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 2/2] RFC: drm/xe: Prevent pinned_link double add
Date: Tue, 06 Oct 2026 18:16:43 +0000 [thread overview]
Message-ID: <sashiko-outbox-162325@kernel.org> (raw)
In-Reply-To: <20261006175741.3582911-2-fnu.vishwanatha@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: Masked list corruption causes system suspend failure
--
commit 2ec4b5f1ac44438a30593cce5cd58f19ac02f193
Author: Kornel Dulęba <korneld@google.com>
RFC: drm/xe: Prevent pinned_link double add
The commit attempts to fix a list double-add by checking if the pinned link
is empty and adding a warning. It resolves kernel crashes on memory
constrained devices running CtsCameraTestCases.
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 98c7c17cc46cc..a5af53b36a5f2 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -3166,7 +3166,14 @@ int xe_bo_pin_external(struct xe_bo *bo, bool in_place, struct drm_exec *exec)
> }
>
> spin_lock(&xe->pinned.lock);
> - list_add_tail(&bo->pinned_link, &xe->pinned.late.external);
> + if (list_empty(&bo->pinned_link)) {
> + list_add_tail(&bo->pinned_link,
> + &xe->pinned.late.external);
> + } else {
> + WARN_ONCE(true,
> + "pinned_link already added to a list, bo->ttm.pin_count: %d\n",
> + bo->ttm.pin_count);
> + }
[Severity: High]
Does this list_empty() check mask the root cause of a desynchronized
lifecycle when a buffer object is pinned by multiple subsystems, such as
external and display?
If xe_bo_unpin_external() is called while the buffer object is still pinned
elsewhere, the pin_count is greater than 1, and it skips removing the
buffer object from xe->pinned.late.external:
drivers/gpu/drm/xe/xe_bo.c:xe_bo_unpin_external() {
...
if (bo->ttm.pin_count == 1 && !list_empty(&bo->pinned_link))
list_del_init(&bo->pinned_link);
...
}
If a subsequent display unpin happens, it calls ttm_bo_unpin() directly and
drops the pin_count to 0, completely bypassing the external pinned list
removal:
drivers/gpu/drm/xe/display/xe_fb_pin.c:__xe_unpin_fb_vma() {
...
ttm_bo_unpin(&vma->bo->ttm);
...
}
This leaves the unpinned buffer object stranded on the pinned list. During
system suspend, power management eviction encounters this stranded unpinned
buffer object, triggering a warning and returning -EINVAL:
drivers/gpu/drm/xe/xe_bo.c:xe_bo_evict_pinned() {
...
if (WARN_ON(!xe_bo_is_pinned(bo))) {
ret = -EINVAL;
break;
}
...
}
Will this cause power management eviction to abort and break system suspend?
> spin_unlock(&xe->pinned.lock);
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261006175741.3582911-1-fnu.vishwanatha@intel.com?part=2
next prev parent reply other threads:[~2026-10-06 18:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 17:57 [PATCH 1/2] RFC: drm/xe: Fix pinned list UAF panic FNU VISHWANATHA
2026-10-06 17:57 ` [PATCH 2/2] RFC: drm/xe: Prevent pinned_link double add FNU VISHWANATHA
2026-10-06 18:16 ` sashiko-bot [this message]
2026-10-06 18:15 ` [PATCH 1/2] RFC: drm/xe: Fix pinned list UAF panic sashiko-bot
2026-10-06 18:37 ` ✗ CI.checkpatch: warning for series starting with [1/2] " Patchwork
2026-10-06 18:39 ` ✓ CI.KUnit: success " Patchwork
2026-10-06 19:38 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-07 1:17 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-10-13 22:06 ` ✗ CI.checkpatch: warning for series starting with [1/2] RFC: drm/xe: Fix pinned list UAF panic (rev2) Patchwork
2026-10-13 22:08 ` ✓ CI.KUnit: success " Patchwork
2026-10-14 3:20 ` ✓ Xe.CI.BAT: " 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=sashiko-outbox-162325@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fnu.vishwanatha@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.