From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 499FD47F3A6 for ; Fri, 2 Oct 2026 10:08:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790935744; cv=none; b=jopsPhIBlp65Ls5g8Z1d8zz5OA5ojrHNIQhn2zF0bKTuXE4oTJwNHXbiv1chDqfQykiPap8GVLwBEiD7Q3DXkU9dch6tdVefseipwTgmSj4pjO7czDleqDANsAzfSxMxttJck9Uxys+3tX7f403Qcf0JOFjEDmiTyCxNrmgbR6Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790935744; c=relaxed/simple; bh=yjjML3TEOgvLOEz6ww+az4hbewCjhc7BX5Kh4C/2Q3c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rn+C8UJLFaSJyxP03OSvnqfWF6h1eDqQPQstHgMHx3f3NdAxBKXcAQIg6Tx118kMNbG1M1JTktoZUtvA+6V22/yNw/goE6L971BZZRa5FsrHo1GVWs7oKO1rOnN3qXjRm5UfhEd05lzRqKJ5Q6uZX6SC+DD3llwFI67F8P6dao8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aU9F3FcM; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aU9F3FcM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1790935741; x=1822471741; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yjjML3TEOgvLOEz6ww+az4hbewCjhc7BX5Kh4C/2Q3c=; b=aU9F3FcM8OSdHkAHSGwLshB+mJyZvt6wgfzNSawmw5K7SiSB0Oo5PwMN QM31wmQoqKnssGN5/c/1L7oNje2OJmaMM49/eDaoyaI4Q/C5ZJyvDsqku wHWub1HIDZb9fWignF73O09crC39CGfFyVeC+1s8OwZyMyxGV9IQIirhN Hh94aK4T5QLR4KNuxDy9C3hKorhVZ95ww2BZPWEo81fWGQUSnzSP5KP/P lmWD3TLCA8MDP98Vo1WFZ26IFWkfcIWj/wbqOA0AKgxC2Mh7LQr5t06OZ 7MPvFLCF/fsHUwPyixvt8rZ+f9q+eOEVYVcbWoM+UDl98lcJpFBdKH9lM w==; X-CSE-ConnectionGUID: e0h2/exZTDCqLEZ/M84hjQ== X-CSE-MsgGUID: kVncSlwDS7CtABv1NdXFCA== X-IronPort-AV: E=McAfee;i="6800,10657,11922"; a="102224580" X-IronPort-AV: E=Sophos;i="6.27,136,1787036400"; d="scan'208";a="102224580" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2026 03:08:58 -0700 X-CSE-ConnectionGUID: pSzW/ituSdy3JiPyiEh2uQ== X-CSE-MsgGUID: HBzRUwWPSPiOzHhoRUjb2g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,136,1787036400"; d="scan'208";a="275412060" Received: from hrotuna-mobl2.ger.corp.intel.com (HELO fedora) ([10.245.244.200]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2026 03:08:56 -0700 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= To: intel-xe@lists.freedesktop.org Cc: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Maarten Lankhorst , Rodrigo Vivi , stable@vger.kernel.org, Matthew Auld , Matthew Brost Subject: [PATCH v3 2/2] drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin Date: Fri, 2 Oct 2026 12:08:30 +0200 Message-ID: <20261002100830.12297-3-thomas.hellstrom@linux.intel.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261002100830.12297-1-thomas.hellstrom@linux.intel.com> References: <20261002100830.12297-1-thomas.hellstrom@linux.intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Cc: Rodrigo Vivi Cc: intel-xe@lists.freedesktop.org Cc: # v6.8+ Reviewed-by: Matthew Auld # v2 Assisted-by: LLM Signed-off-by: Thomas Hellström 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); } @@ -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)) -- 2.55.0