From: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-xe@lists.freedesktop.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>, <stable@vger.kernel.org>,
Matthew Auld <matthew.auld@intel.com>,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH v3 2/2] drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin
Date: Mon, 5 Oct 2026 14:59:46 +0530 [thread overview]
Message-ID: <d116ce1e-abc3-4f4a-8805-6d718416cf8c@intel.com> (raw)
In-Reply-To: <20261002100830.12297-3-thomas.hellstrom@linux.intel.com>
On 02-10-2026 15:38, Thomas Hellström wrote:
> xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's
> pinned_link list membership in xe->pinned.late.external, based on
> whether the current call is the outermost pin or the final unpin.
> However, the same external bo's pin_count can also be raised and
> lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin
> the bo as a display scanout buffer without going through
> xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no
> notion of, or ownership over, pinned_link.
>
> If a bo is pinned both externally (e.g. dma-buf export) and as an fb,
> and the external unpin happens first, xe_bo_unpin_external() correctly
> observes pin_count > 1 and leaves the bo on pinned_link. When the fb
> unpin later performs the true last unpin (pin_count 1 -> 0), it never
> touches pinned_link, leaving the bo linked on xe->pinned.late.external
> indefinitely. Once the bo is subsequently freed, this stale list entry
> points into freed memory, corrupting the list and risking a
> use-after-free the next time the list is walked or spliced.
>
> The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/
> xe_bo_notifier_unprepare_pinned() have the same bypass characteristic,
> though they never add their bo to a pinned list, so are not affected
> by this particular list-corruption issue.
>
> Move the pinned_link removal into xe_bo_account_unpin(), which already
> runs on every unpin path (kernel, external, framebuffer, backup
> object) right before the true 1 -> 0 pin_count transition. Since
> list_del_init() only operates on the node itself, this removal is
> list-agnostic and safe to perform regardless of which list (external
> or kernel_bo_present) the bo happens to be linked on, or which code
> path is performing the final unpin. Drop the now-redundant explicit
> list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin().
>
> Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: intel-xe@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v6.8+
> Reviewed-by: Matthew Auld <matthew.auld@intel.com> # v2
> Assisted-by: LLM
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> v2:
> - New patch
>
> v3:
> - Rebased on changes to previous patch.
> ---
> drivers/gpu/drm/xe/xe_bo.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 6cc3f0bc0be4..5a70e652895b 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -505,12 +505,27 @@ static void xe_bo_account_pin(struct xe_bo *bo)
> * ttm_bo_unpin(), so that the check against the true 1->0 transition sees
> * the pin count that is about to be released. See xe_bo_account_pin() for
> * why imported bos are excluded.
> + *
> + * On the true last unpin, also removes @bo from whichever pinned-bo list
> + * (external or kernel_bo_present) it may currently be linked on, since a
> + * bo's final unpin can happen through a pin path (e.g. framebuffer,
> + * backup object) that has no notion of, or ownership over, that list.
> + * This is safe and list-agnostic: list_del_init() only needs the node
> + * itself, not knowledge of which list it is threaded through, and is a
> + * no-op if @bo is not linked.
> */
> static void xe_bo_account_unpin(struct xe_bo *bo)
> {
> struct xe_device *xe = xe_bo_device(bo);
> + bool last_unpin = bo->ttm.pin_count == 1;
>
> - if (bo->ttm.pin_count == 1 && bo->ttm.ttm && ttm_tt_is_populated(bo->ttm.ttm) &&
> + if (last_unpin && !list_empty(&bo->pinned_link)) {
> + spin_lock(&xe->pinned.lock);
> + list_del_init(&bo->pinned_link);
> + spin_unlock(&xe->pinned.lock);
> + }
> +
> + if (last_unpin && bo->ttm.ttm && ttm_tt_is_populated(bo->ttm.ttm) &&
> !xe_ttm_bo_is_imported(&bo->ttm))
> xe_ttm_tt_account_add(xe, bo->ttm.ttm);
> }
LGTM
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> @@ -3322,11 +3337,6 @@ void xe_bo_unpin_external(struct xe_bo *bo)
> xe_assert(xe, xe_bo_is_pinned(bo));
> xe_assert(xe, xe_bo_is_user(bo));
>
> - spin_lock(&xe->pinned.lock);
> - if (bo->ttm.pin_count == 1 && !list_empty(&bo->pinned_link))
> - list_del_init(&bo->pinned_link);
> - spin_unlock(&xe->pinned.lock);
> -
> xe_bo_unpin_account(bo);
>
> /*
> @@ -3348,10 +3358,7 @@ void xe_bo_unpin(struct xe_bo *bo)
> xe_assert(xe, xe_bo_is_pinned(bo));
>
> if (mem_type_is_vram(place->mem_type) || bo->flags & XE_BO_FLAG_GGTT) {
> - spin_lock(&xe->pinned.lock);
> xe_assert(xe, !list_empty(&bo->pinned_link));
> - list_del_init(&bo->pinned_link);
> - spin_unlock(&xe->pinned.lock);
>
> if (bo->backup_obj) {
> if (xe_bo_is_pinned(bo->backup_obj))
next prev parent reply other threads:[~2026-10-05 9:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 10:08 [PATCH v3 0/2] drm/xe: Fix two bo pin/unpin accounting bugs Thomas Hellström
2026-10-02 10:08 ` [PATCH v3 1/2] drm/xe: Fix shrinker accounting double-subtraction on nested external pins Thomas Hellström
2026-10-05 9:24 ` Ghimiray, Himal Prasad
2026-10-02 10:08 ` [PATCH v3 2/2] drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin Thomas Hellström
2026-10-05 9:29 ` Ghimiray, Himal Prasad [this message]
2026-10-02 10:16 ` ✓ CI.KUnit: success for drm/xe: Fix two bo pin/unpin accounting bugs (rev2) Patchwork
2026-10-05 7:51 ` ✓ CI.KUnit: success for drm/xe: Fix two bo pin/unpin accounting bugs (rev3) Patchwork
2026-10-05 8:55 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-05 10:41 ` ✓ Xe.CI.FULL: " 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=d116ce1e-abc3-4f4a-8805-6d718416cf8c@intel.com \
--to=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stable@vger.kernel.org \
--cc=thomas.hellstrom@linux.intel.com \
/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