From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 EA10E30148A for ; Thu, 21 May 2026 15:08:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779376130; cv=none; b=VOu9C5kfTAk8yFO/PmUdPDFAFW4Hi2H4/4J1htIe+bAmRuXkTIsGB1u+3jaqJTspkpDmWlwi7cYJR4Nxqfo6CN4cyxtizH+YyLUU1XT6BkD5RCsQxW/J/V9olmgyisOwUswkAK6fY/CNxOnEgpaJs6AQIwqfsoJByR66Sfo/NbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779376130; c=relaxed/simple; bh=AqerENhdAVb1dK1V71iWIYNJydIUcNCZTL4O4bhZuBU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZLAYHxE4NHyY2pg37ISJ550KJbfowZoZwrI/yMYGmoj1OEOdPEgnlneqojN6whogSUROAjPR0rJuaGUtRwA6CIgfFuaUeeOUsO6lp4BnwfiplyzpBSJ6ya9D7/pJe4n5dHuPZwqwky9Y1cut/rWgP0c3PgR+IEp6wnCwKWxuJZ0= 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=W+WWTYxG; arc=none smtp.client-ip=209.85.167.51 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="W+WWTYxG" Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5aa2691db86so3753914e87.3 for ; Thu, 21 May 2026 08:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779376127; x=1779980927; 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=mR8YNzhzHv5g5ezNdxi/IR56+HrSSzrEa6IF1DOutaU=; b=W+WWTYxG5smONszWmxMinWPHLyt74AOuCQb5JcWNmGZ/vcCpwYlwY8wodCZUVAgUdX pgs7cg3cTcJe5FIxt1Ezj6ezAu41TvmbmYX5Xeezq5eBIcI9bS0+uRbO70LAsh+ljdkk r3egPc6DcFrw4WPkVSU4/i9wA6Y6aYAMWhI/+9cDUULAKL8RuVWN6mticJD/cI/rh65a MVl25cvpf3BzjXHmKnblGkyg/OqWiViLYoRAC8yJFOWcj3pauTmfOFDPgG1iFV1Vo9dE iM0YQxZcsPukTanaVP01JNarav7GafHnKuqH6S3hprUkK6mtwgrebKVDK7Mh1Te5R1yT tU+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779376127; x=1779980927; 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=mR8YNzhzHv5g5ezNdxi/IR56+HrSSzrEa6IF1DOutaU=; b=EPUK9MhpI5hukO9GTtw+wRm5vZ2U7l1kWNVczeS2BILTyXdL8TArkCZX0/bK7iF22i nEa+kyLqfHNMdXSwLXSQInTo9SzNOvk/HI72F1QvEy+8WFwuSu4nZXxyH7ZANMnptIC7 BgkWXaWudrwLcSOf7LFm/cvT3iCQIEEVo28pq5KCBRrxZYeVOzjBk1R+hzA/ebiYN6iD g36VcwJZwOVEvylPvRYNtuq1NebqR8cJW7wDS1+UpKkCHxNWliK8Gog0ILt6QJVi+ZvT WYWjfOZLTgat2f/9n8fd2ngYQlMHA6LVUj8jc7QeLWD3UHCRF6IjTq2TEFvw8bg2Khhp MQdA== X-Forwarded-Encrypted: i=1; AFNElJ9ZOkYw+ZvPa96pZ9FZfsacJ8lfwfWWGnOGOVzHRQP5g6bQUUFnPA/uxAy+7i4Wxl8qGmK7PhfRn6q1Wts=@vger.kernel.org X-Gm-Message-State: AOJu0YzFuyzrHtfvoD7F6ify3bSVSzpKZZbrpdOYTeFd386hFiDKysHG /Jiks67sYLVpc1c44YhJKZQn/EQiI+Cl0hicGZqjumYlqFQBcxjfYdeq X-Gm-Gg: Acq92OGqTILDxEJUEZrl93+aBjeioeU9v8Pz/IXRcFjOAWd21CeNVhggP8z1UMmOG1z mkS54qxVw9mTItYe7bXoeFC7h0l/Jc9YkV81jcNM/BLZ8IGMUFO3vzqau4v7nX0OgarF8/VBK5x kHJv01o17JSm432dyNZR3kwtlTOxVfrQDyXosjcHzKVE8tEqN7HkfOVxU6KvYf3F9fg4BM0TrHh mp3pF4Gn6xxoXNi1WP2DYDPzt1e1a7mbPRJADfOm8gHmGHIwudM2vU2r6awrRUZ7hB7O8mBsIf+ OFdlIUTuj/+1QC4y2s3P14qg7SlSIMz/7jBMy9RxUYQPvrip4P5boDvgnkVxlsCRb+6ZSGqvKAt iDnDF0hpisShvdLVAoSGfsgSxYEojN4hwy9lY7VOf7nllq6IZ+iT7V3PR2vtPbkycIHoxLvCflH 3M1HMCOCpBtE9KgMD50EY/AW0ZIynJaHe6TMm6jjQq2I4= X-Received: by 2002:a19:7001:0:b0:5aa:265f:acd0 with SMTP id 2adb3069b0e04-5aa2bc90bacmr751255e87.39.1779376126773; Thu, 21 May 2026 08:08:46 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5aa2f120c6esm335686e87.19.2026.05.21.08.08.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 08:08: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 v5 0/2] drm/amdgpu: fix recursive ww_mutex in devcoredump IB dump Date: Thu, 21 May 2026 20:08:38 +0500 Message-ID: <20260521150841.20625-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260521104335.28978-1-mikhail.v.gavrilov@gmail.com> References: <20260521104335.28978-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. The fix teaches amdgpu_vm_lock_by_pasid() to lock the root PD in a drm_exec context, so the devcoredump path can lock the root PD and all the IB BOs together in one ww ticket. 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 with drm_exec_lock_obj(). The drm_exec context holds the root BO reference, so the root output parameter is dropped. 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 IB dump is produced correctly. 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/ v3: https://lore.kernel.org/amd-gfx/20260520151741.50575-1-mikhail.v.gavrilov@gmail.com/ v4: https://lore.kernel.org/amd-gfx/20260521104335.28978-1-mikhail.v.gavrilov@gmail.com/ Changes since v4: - Pass nr=1 to drm_exec_init() in amdgpu_vm_handle_fault(), since exactly one object (the root PD) is locked there (Christian). - Picked up Christian's Reviewed-by on patch 1. Changes since v3: - Lock the root PD with drm_exec_lock_obj() instead of amdgpu_vm_lock_pd(): the latter dereferences the VM pointer, which is not yet re-validated at that point (Christian). - Drop the root output parameter of amdgpu_vm_lock_by_pasid() entirely; the drm_exec context already holds a reference on the locked root BO, so the extra reference and the parameter are unnecessary (Christian). - Unlock the root BO with drm_exec_unlock_obj() on the VM-recheck-failed path (Christian). - amdgpu_vm_handle_fault() and amdgpu_devcoredump_format() updated for the simplified signature; both lose their root variable. - Drops the v3 kernel-doc "*root" reference, which also resolves the docutils "Inline emphasis start-string without end-string" warning the kernel test robot reported against v3. Changes since v2: - Reworked along the lines Christian suggested: amdgpu_vm_lock_by_pasid() 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). The amdgpu_devcoredump_ib_ref struct and the three collect/lock/release helpers from v2 are gone. 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 | 105 ++++++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 91 +++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- 3 files changed, 129 insertions(+), 69 deletions(-) -- 2.54.0