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: 4+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox