From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 8773F349CDD for ; Thu, 21 May 2026 10:43:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779360225; cv=none; b=i74pYvv+kEHx32tpEF60J147w2XbaBarzh5G8g3Ae2BxVNCIQEwQ8VJ6EF9d/kxmV0ltl98JdhgKfumt/5XjPl47f36x0Z9WqlO+un94gQCi2ZhdUU24PXXoKyzikRoQ5VS3is04NSpWx8zAnGluuNiFlJsdjf1n/gAdKKVWzfA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779360225; c=relaxed/simple; bh=C8h6cW0KfHk9tKmw4KDbEe36vorCimxRnFUO/tEuMJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GrPV5r/T3ymfcgSNBkbfN9UP5ubCq/nVzi6KNLNL2lmnj58wEYJ/xepG3/rV1tLSHXRafgYNWV/6oAEuo9IqpvCnHfB/JudYW8xltNLBbn4O/yFf5Ds66BfD5Txh8cQhXGD3APyDiQe3OXikGK/d6kM4DtTGMS6+Nt6cyYZ3pKs= 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=Phr0CCnC; arc=none smtp.client-ip=209.85.208.178 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="Phr0CCnC" Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3922b35e69cso52726051fa.0 for ; Thu, 21 May 2026 03:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779360222; x=1779965022; 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=IotSskqgPt1trYIpm3eRWveVqEambqTQS5bkqN0X6AA=; b=Phr0CCnC8/6+2UEQ421puoOI6f6TTXemKoKLq/o1+sKjqAbBCrSPRExWCsrMjKdD74 Vls3vju910hKWPNFshAfOxLWwZfRNo7//jAtY3/ktS3/6DKwcCKBkixBGHtl5deSjfvg 0HJj6MjpQbc08hSXLPXyFmL/kc3rQKZTWt10PcIW/BtfUsBPkc8qxU3D+ReIFdSX83p7 LowEyepDnHjOtZMShu4HVH8DQoVo2jt92KTE8mS28E3B/dsNT2DSkSEnNbY0LxiGVPKY 1P1Hx/V7qprlKrswP8159cBJMsRTfxXdGOI/lN8tDTZO5wbl5KIEbF3e3Yl8uLtob4CX F7+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779360222; x=1779965022; 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=IotSskqgPt1trYIpm3eRWveVqEambqTQS5bkqN0X6AA=; b=WzIGxlB40ADu0gPV9MZPYRbW+2FFYEj1/8BwZwiSyro3Wss9PN3gEAaB75uJDtJQ8e dtPp2Kk1t98ucCduNzHG4CVU6QFG8YgefrME+qeD27SoAvE9qlZy9n1QmtC/QQoMhK7+ b47wYkzcTB4G8QBCAe0zgLdbpXWSA7jdPF9ePGvp3+T4KJDNmN2v/zZ/B6iwXYzOOn9m LtFPTqVM2gWOEcrJ1gbvffhd2PZaeeucpiIz0lcOiK6++Scq1VebdPmeSBuOvDP7tGIu TPp80ZuhrbwFD/khGkBs8vcEf/i4/572HB+Ep0PXD0EtzFa9dGW5OY7ExhgkQQy9dRVw S6iQ== X-Forwarded-Encrypted: i=1; AFNElJ/9IR2R8jZ9R+rmQyORUdnjzLpl12JGd+1dertSEVldjlJjTIoLfktdEg7LGPwPyzKlX6L78UoTcds1lLM=@vger.kernel.org X-Gm-Message-State: AOJu0YxMftIoVb7Hg9I8Tyff/LA2JyPj2vBBQBlma//J8d/Pghg7pTvA is4nkgTtlnD5+pgFCUmbLUB33S5CvOuqvaolFYNliDN3jYQLzwSCLPMB X-Gm-Gg: Acq92OGR/5HxltndJ3NuRfImZXyhXz7AlA/AyxCScZjJ90BMpPcl/HSclq1aKYTzrL5 g3ccb/I27eC0ILC86zPIUjozponVxz7o14RU/T0NlP+oIMRiYl6u3TSjWWZKk9M8ZXxXWua8wwP jR6JAeyqN+lsyZ6ZsHB4uDrYebuZnKxlGeZxqNTWpSWzX9kPfMvMnTFB5xaowlOe+l1sxHmsUCf 4VmC4Xc4NjNYV70QzsSHCgY2JiQ2ZRS+WuRVOYGTfL2YxV5JQSAZtRDO1bAp67gEsB9MXOLQF2o 1Hy0eR+tTtpJDnRQiJVa/ZoiwyYbBL6u0PMdLEmLAjqFNPDkeF2MZVfcZB19L2H5cf+923tmHbA a5OfOnL2UMJ0IcbqGeP0pbXb6N64gZwEe5vfosr3HtSv+Niyw82UF2M5lXCBjHIJnCQGuIJQflQ 4jcKuPnROiua6awdOPlIMX1XXE0lTE8UMw7kHls3Ogwm9Y X-Received: by 2002:a2e:be89:0:b0:394:2b8a:2348 with SMTP id 38308e7fff4ca-395ca644e5amr9678271fa.20.1779360221305; Thu, 21 May 2026 03:43:41 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-395d0b49073sm1595611fa.31.2026.05.21.03.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 03:43:40 -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 v4 0/2] drm/amdgpu: fix recursive ww_mutex in devcoredump IB dump Date: Thu, 21 May 2026 15:43:31 +0500 Message-ID: <20260521104335.28978-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260520151741.50575-1-mikhail.v.gavrilov@gmail.com> References: <20260520151741.50575-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 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/ v3: https://lore.kernel.org/amd-gfx/20260520151741.50575-1-mikhail.v.gavrilov@gmail.com/ 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