From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 560A93EFD22 for ; Wed, 20 May 2026 15:17:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779290272; cv=none; b=HkMGdYD8aEv1CN9WC6sbyc0a4iMXBI+FY2e/7NiGuLAS/5lRO+GBYMNuR3Bct7HLr1P8lgo4mBUn+W8Sd0apU/utH/iJ2MH8ZLTghNebXbD7fok0hKXzu8umsl/sMJUDBiCjFsGlF/Ptv7zW4eWDsaCdVWXIWDO4x+qzCyGYoZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779290272; c=relaxed/simple; bh=A8s9eIZWewOU5QRyqXcZfjU7uq75uKfqUxvVF4rbh0M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ti4nrQCvI2rLtDOeVn86eGIoD8FMgd4CNKrEeyu87SUSOu7Gq1ck9scoRuHDV937fztnAU7/qm2huTcz+vCIAqwRS9wL4ojAqpPG5Ntk1duwk87HwDf88lPl9LEmAeK5KNMyYUwLEj96zTtNbeQYeY5v0K8jatuKJBWsGMS7gZM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LKuYyJPi; arc=none smtp.client-ip=209.85.167.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LKuYyJPi" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5a887ebb416so6122711e87.2 for ; Wed, 20 May 2026 08:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779290267; x=1779895067; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ircF4PWSycvWSmAyVL8auld82Bsa3FQOWa7WNmN+a+A=; b=LKuYyJPibVy1pd2DqY5maDDKR37U2namfeN4N/X5ftrIzZcRWfb2bw9S+9VQsPbBVh Lud0zSzXpzrVvxshW+bxP9rVSpjRFdY9CKcS7Fc3ZXXvHZGpPP61aAxU2W5ew12Urpx7 hQ8mJ77dfdi2hkufbZZzRcIkUn84yJLjzmj1UQP7KPdaQT1KOBQuZpIKDwrt8MIuPjmU l9UhhnLY1XmfBjZUTwNgerO3Sv5HRQccQsELgTDcJrWdxPDKm9RNFW/L3HTDYJbZNqGa IBPdMWlp10VWlsO3N3ZrSD0wo8+SK5REHIxViBn5SU7ojlG4Fue7QzgtxPmAOcahYZFV 2bNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779290267; x=1779895067; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ircF4PWSycvWSmAyVL8auld82Bsa3FQOWa7WNmN+a+A=; b=L5LG+FnXFDlYUM+Fn+m9NS/ubkxYG3WNUTr21xLohYn3iamcJQc/XerqALJxcxBlhE o/Ky+rvt5qBz1rSJhKOCmgPk4P9pg7juWSKxw1T8x6iOBXmMEjG8ywi5MrXB+l/Gh1t+ 1hWeZojY7bXSgfn9KaAb6cGM0ihg+uyD4vAFcn2QGc8bk8yAS4nTweWxnymHfJA3ViF8 7MLBxWNB2DeQgGmSpEjqn/Q/z9E20EsoRseToakMFl2cbT0G6DpvbDhIkrKvRZnvNDWV alOYiNQW1z0rxMgREQEO5xvaGkwtcHGA67qxo6LRndVf76q7j9oUIFB1411jr54NvzPl zQeg== X-Forwarded-Encrypted: i=1; AFNElJ+LPNeKZ6kmmv0Bq1/VhflIrfWrzru8Bi6lBQQQxEUpe8ulDh/llFJm5TpWzqQKqc7j1s/51vrXjerMelk=@vger.kernel.org X-Gm-Message-State: AOJu0YxtNvWfIV+trd2WA5dxyapRYxsE8l11u0LMjzQSfr+64b2PJi+n mwGdOYN3Fwl9HaZ0aRl6yc9LHJnbH+20j6DW/4JvlJi3ws+saDdu4bmx X-Gm-Gg: Acq92OF32I8NeLP3ace5ix3zTn13XMKgcMYJeu56FPT71rgHUH7odVPu8JcMhXjjEcm D88whpvcxdAbmCAOmZYb/UVJJycqpFqKXizrcMr6MlmxuDVidFIM/4KfOlUiyL9kIpZ3AU/r+1R r5wU9Q5sqCIB/60iAnhoGMHxZNrYZutWFT/mi3cmB+iZDWI8u1RmU0oyr0kSNvr27Cd6JBYv+th BE92Lc/FjeGZxuxGLlxAjSFxcEBjnsuhQpbQQh7LqWNrcvNDZR8uZVnYBQKzAemADjovdAgLN9P nzyweD5E53IEr74ffSMs+3oP9Eoj/QkzbcAYWE787e5ZCS0Q01iYuBBoyDva9vMitppIHvo5AcX uNvuRFRyDjognm8cJ52Waleo/bihxKdCJZ2h7NRIf9a97UNg9fM6aPKCOA2G512y3KfPq3Zb674 imK0s1dXtHfOCKYG3hJ3git0wEU3WjIM6T X-Received: by 2002:a05:6512:1252:b0:5a4:1672:59d0 with SMTP id 2adb3069b0e04-5aa0e7278f0mr9211402e87.19.1779290267082; Wed, 20 May 2026 08:17:47 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a90f10c8b2sm5022470e87.17.2026.05.20.08.17.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 08:17:46 -0700 (PDT) From: Mikhail Gavrilov To: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , David Airlie , Simona Vetter , Pierre-Eric Pelloux-Prayer , Sumit Semwal , linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Mikhail Gavrilov Subject: [PATCH v3 0/2] drm/amdgpu: fix recursive ww_mutex in devcoredump IB dump Date: Wed, 20 May 2026 20:17:38 +0500 Message-ID: <20260520151741.50575-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260429143743.50743-1-mikhail.v.gavrilov@gmail.com> References: <20260429143743.50743-1-mikhail.v.gavrilov@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This series fixes a lockdep "possible recursive locking" splat in amdgpu_devcoredump_format() that fires on every GPU timeout once a job with a PASID context is involved. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s, so the splat repeats until it drowns the kernel ring buffer. It is also a real self-deadlock for IB BOs that share their dma_resv with the root PD (the always-valid case). The root cause: amdgpu_devcoredump_format() holds the VM root PD's reservation and then reserves each IB BO on top of it, nesting two reservation_ww_class_mutex acquires without a ww_acquire_ctx. v1 fixed this with a snapshot helper that collected BO references under the root reservation and reserved them one by one afterwards. Christian pointed out that drm_exec already solves exactly this — lock everything in one ww ticket — and suggested teaching amdgpu_vm_lock_by_pasid() to take a drm_exec context. This v3 follows that approach. Because amdgpu_vm_lock_by_pasid() has a second caller in the page-fault path, the series is split so each patch builds and works on its own: 1/2 Convert amdgpu_vm_lock_by_pasid() to take a drm_exec context and lock the root PD via amdgpu_vm_lock_pd(). Updates the existing caller, amdgpu_vm_handle_fault(). Pure refactor, no functional change to the page-fault path. 2/2 Use the new signature in amdgpu_devcoredump_format(): lock the root PD and every IB BO together in one drm_exec ticket. The per-IB amdgpu_bo_reserve() nesting is gone, along with a BO refcount leak on the old reserve-failure path. This is the actual bug fix and carries the Fixes: tag. Tested on Linux 7.1-rc4 + this series, Radeon RX 7900 XTX (gfx1100), KASAN + PROVE_LOCKING enabled, using a small libdrm_amdgpu reproducer that submits a GFX IB chained at GPU VA 0 and waits for the hang. Before the series the splat fires on every TDR; after it the dmesg is clean across repeated timeouts and the devcoredump output is unchanged. v1: https://lore.kernel.org/amd-gfx/20260429143743.50743-1-mikhail.v.gavrilov@gmail.com/ v2: https://lore.kernel.org/amd-gfx/20260519161541.19994-1-mikhail.v.gavrilov@gmail.com/ Changes since v2: - Reworked along the lines Christian suggested: instead of a private snapshot helper and a separate drm_exec pass, amdgpu_vm_lock_by_pasid() now takes a drm_exec context directly (patch 1), and the devcoredump code locks the root PD and all IB BOs in a single ticket (patch 2). - Dropped the amdgpu_devcoredump_ib_ref struct and the three collect/lock/release helpers from v2 entirely. Changes since v1: - Switched from per-IB amdgpu_bo_reserve() to drm_exec. - Dropped the Cc: stable tag: the regression only landed in 7.1-rc1, so the fix reaches 7.1 via drm-fixes without a stable backport. Mikhail Gavrilov (2): drm/amdgpu: convert amdgpu_vm_lock_by_pasid() to drm_exec drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format .../gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 103 ++++++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 72 ++++++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 +- 3 files changed, 122 insertions(+), 56 deletions(-) -- 2.54.0