From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 67A0C29ACC5 for ; Tue, 28 Apr 2026 09:45:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777369515; cv=none; b=Fb6DwE7x+UqxWHFPQjrTMp3K9XkfjH1J1e8DoVhAMDxt8kCs9YQo6ZQznDEH4cX1UjfukM2pcVyJRW/i6XCS4FguVkM4F+pTw5hvBcLG5RpLkWi+kIBMEeDKfK6HKDOU4E/fEvEnJP7gQmRwLseYbpOGZwlwG5+JLicWTb5magY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777369515; c=relaxed/simple; bh=HtsGNwL7hZ0zkDzN6OgQLhPV3N5XrvY+T6jNJxzmLCE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=MXD8sH0dxobF8D2nF212oXZJFj6v7HK+RBP0Zw9AvE+8YL1IM0+M4+Z0VSyEXc5za6gGk16sQrQAmqnp3WV2hmTVYh7lmc0fc2lyPw1W6m8N1ao5WKxLqllaexk+1caRCdCN894+gz/YkglCiqL5r3LGsMPYG1Mug4gOhGfQykE= 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=aDsg10fE; arc=none smtp.client-ip=192.198.163.10 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="aDsg10fE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777369514; x=1808905514; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=HtsGNwL7hZ0zkDzN6OgQLhPV3N5XrvY+T6jNJxzmLCE=; b=aDsg10fEEP0oSazkfXl8+It+8E/lAOzeWfVwHTyfk2lOzTFBSL97lt+K ebbgPAkx8tuVlMKujnxuYnDJzKBHp3xEvaQh6QvpIRIgMwoTsmYyifb7p ViP6oItKD5gw5Ngu6RScF4HAtR5fcmwqPFf+VVyFa3Lyy8yX7PvRNT2Gi LitZnpH9WnWXxQRam7DFGykVcxMpgi3MCBNvmi/sW8jP76eWM4QvBCMwf w8nPLx6vDx6SmOH92bP/P9d2FO62SZmO4E8ZsR+sp9rwPqVSDEbSTn0Z7 OM1JlloGKNa+vxVh1rIQDCF+J4TXWIS/CqD/c5SB7BgccQSEFgv7+snNK w==; X-CSE-ConnectionGUID: dtOaHOROSyC3kK/DEqSuPg== X-CSE-MsgGUID: NfIskrBIRO26DTf066Ia8Q== X-IronPort-AV: E=McAfee;i="6800,10657,11769"; a="89652816" X-IronPort-AV: E=Sophos;i="6.23,203,1770624000"; d="scan'208";a="89652816" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2026 02:45:13 -0700 X-CSE-ConnectionGUID: B6lNAgBATgqUnABcneHejw== X-CSE-MsgGUID: pFBO/0EOSiuvmZStuD/9MQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,203,1770624000"; d="scan'208";a="257439238" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO fedora) ([10.245.244.161]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2026 02:45:09 -0700 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= To: intel-xe@lists.freedesktop.org Cc: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Jatin Kataria , =?UTF-8?q?Christian=20K=C3=B6nig?= , Matthew Brost , dri-devel@lists.freedesktop.org, stable@vger.kernel.org, Boqun Feng Subject: [PATCH] drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure Date: Tue, 28 Apr 2026 11:44:42 +0200 Message-ID: <20260428094442.16985-1-thomas.hellstrom@linux.intel.com> X-Mailer: git-send-email 2.53.0 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 When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. Reported-by: Jatin Kataria Fixes: fc5d96670eb2 ("drm/ttm: Move swapped objects off the manager's LRU list") Cc: Christian König Cc: Matthew Brost Cc: Cc: # v6.13+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Christian König Tested-by: Boqun Feng --- drivers/gpu/drm/ttm/ttm_bo.c | 16 ++++++---------- drivers/gpu/drm/ttm/ttm_resource.c | 13 +++++++++++++ include/drm/ttm/ttm_resource.h | 2 ++ 3 files changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index d85f0a37ac35..293401705542 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1177,17 +1177,13 @@ ttm_bo_swapout_cb(struct ttm_lru_walk *walk, struct ttm_buffer_object *bo) bdev->funcs->swap_notify(bo); if (ttm_tt_is_populated(tt)) { - spin_lock(&bdev->lru_lock); - ttm_resource_del_bulk_move(bo->resource, bo); - spin_unlock(&bdev->lru_lock); - ret = ttm_tt_swapout(bdev, tt, swapout_walk->gfp_flags); - - spin_lock(&bdev->lru_lock); - if (ret) - ttm_resource_add_bulk_move(bo->resource, bo); - ttm_resource_move_to_lru_tail(bo->resource); - spin_unlock(&bdev->lru_lock); + if (!ret) { + spin_lock(&bdev->lru_lock); + ttm_resource_del_bulk_move_unevictable(bo->resource, bo); + ttm_resource_move_to_lru_tail(bo->resource); + spin_unlock(&bdev->lru_lock); + } } out: diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c index 9f36631d48b6..0e5f1582f13d 100644 --- a/drivers/gpu/drm/ttm/ttm_resource.c +++ b/drivers/gpu/drm/ttm/ttm_resource.c @@ -292,6 +292,19 @@ void ttm_resource_del_bulk_move(struct ttm_resource *res, ttm_lru_bulk_move_del(bo->bulk_move, res); } +/* + * Remove a resource from its bulk_move, bypassing the unevictable check. + * Use only when the resource is known to still be tracked in the range despite + * the BO having just become unevictable; asserts that this is the case. + */ +void ttm_resource_del_bulk_move_unevictable(struct ttm_resource *res, + struct ttm_buffer_object *bo) +{ + WARN_ON_ONCE(!ttm_resource_unevictable(res, bo)); + if (bo->bulk_move) + ttm_lru_bulk_move_del(bo->bulk_move, res); +} + /* Move a resource to the LRU or bulk tail */ void ttm_resource_move_to_lru_tail(struct ttm_resource *res) { diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h index 33e80f30b8b8..a5d386583fb6 100644 --- a/include/drm/ttm/ttm_resource.h +++ b/include/drm/ttm/ttm_resource.h @@ -448,6 +448,8 @@ void ttm_resource_add_bulk_move(struct ttm_resource *res, struct ttm_buffer_object *bo); void ttm_resource_del_bulk_move(struct ttm_resource *res, struct ttm_buffer_object *bo); +void ttm_resource_del_bulk_move_unevictable(struct ttm_resource *res, + struct ttm_buffer_object *bo); void ttm_resource_move_to_lru_tail(struct ttm_resource *res); void ttm_resource_init(struct ttm_buffer_object *bo, -- 2.53.0