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 4C8163AA9E8 for ; Fri, 29 May 2026 06:48:21 +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=1780037303; cv=none; b=gRsjV4xfD/azXOVRG4ZCxihdPXjeO79EsR9wIlaC/TxLJ8Vbwds0MZqw+JcSeCXuPt3k57cfTEXZbLvfDA4qO7ZCG7WZW6QGOSceeBAekqUeN/jULh0Cy0aYI5RYmK9OOdU95o07QfoqEElUHxePoVTqFGV8imQ3v9IDmXWi5p8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780037303; c=relaxed/simple; bh=vxKwswKmvDwSygW/i91TX5sMpAhDAEGevnNHF02W6do=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Df9CKq+oV9ahTeydbIf7mISKvLaDp++Ion2yNL9sOnXq05vhxgfU7SClSkhs6R1JLK2Qq1/y4MpEUA4+WlfMHbg/vRLFGTbhiNjlrvB/GdJUSYhWyczsOwGjT1iMhiOTffOGuCjmztJrHYLb07QpB1ZDKCWr9fAlklEokTDQ0T8= 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=J1CzltVf; 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="J1CzltVf" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5a995ab70d1so15945090e87.3 for ; Thu, 28 May 2026 23:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780037300; x=1780642100; 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=doPRw5QapmDdqAPGgFbdNczGbZz+3rVnzTYKju4SbAA=; b=J1CzltVfqzVnQwZAXv7tXQQHeHwae2GJqoFPxPAVIIUew2ibUyPVSm2xLVHWA17kpN ZpTFMa4Msw6bxwJU8ddg80HsaWqGf8qQHfcUuVw/IR7JLWvYpefQ+lhiFrY24phw8YlX vXe8+Y9cVjrvtSr4BAmpkiOILRacyrzKA9rIATMAYSrLzdV3bN4UnIytBCKKEb+cDBJE nwhmruo+lE7UecIy3ZaTEMJGQJNsOhG1KGidpekx1fNx+aDzTNkSF9F+xtKQUFyZHbqf HteybHEQwaOTLq5+CwgWtFem4Nd600MhJN29bUgrPsA24U6UG4jezEcpN70jBEBRATQA 37Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780037300; x=1780642100; 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=doPRw5QapmDdqAPGgFbdNczGbZz+3rVnzTYKju4SbAA=; b=EmqMuPQikndr7xmtHKOJQY1HjoLJ2ORP6CY1/+zh8+2pUFZRJckXTHWil6/KAmjCpD 4WAN1HDZeAHJX8DjZhyYHDq0KLekCo4mC0r801MDYzKlAoQSGp7DY3eYoBBryxnHmkP/ fhfQuCAF3/b94QYXSZJq42kafmkYdCEltr6NU/qcWBJT0oZvEgTT5Mj5qFfd7Ohtm3qr UpnX2UZLJ4Yjiz80Vh3jed/ADtsTjyRibZ5n9+DeKd5yKU162N4mh3rUQI3iVb+7Zh6a vo95M+NLPRjQXgYpB1Cg2MStLlPyPyJ0tQLEERWyhv7/Lws5kiHgw2d0PTOhuD7A3oFL lEzw== X-Forwarded-Encrypted: i=1; AFNElJ8ux5gB0a/dGfESXBdPHHHLNObyUk6QsyAgH6M8V3CI7o6fjDbgP9F37sF6bQOtExlSZFlkCgUjlbmbj6U=@vger.kernel.org X-Gm-Message-State: AOJu0Yzxld+Ms81HD2bAHnhVEIJ4vVn3YUg8B3KcZkQgNmyFqUOJihAK ukBrzF38a0SZk4xpITel6ul6dNgRNEGPu5Og4BgCt5wUBuayApxOgRMs X-Gm-Gg: Acq92OEBCtoStIOO54bvTtaWU81ibrJywhSHf/spHTxIPGKn0PxEg1yNWDbl13tXgL5 i00CAx3LtLdH0an5kBOGfS95SoZ3qznFvV89Y/049FN5ufh4H1FYbPY6Y7W37Ioc7j/grvb49Sx 4eg1l1SUFFuK+Ij4YQOENcvbP31EhcZFmk6evp3WzVlxtY97ybR+1F3CGw6AxhGUkWld3dVpba0 v158EFQk9ms0NsQLPzFAZn35Ux0DG4iU3h82jWTPr+OHlUfLt2zOztssPxI5hhjxSVzSvLKxT2N YrVOkcJWOBQULB6ltxP7cQCVFc+oO0VcEGvijuG81GFbS3tmYQCHeZOTKiEHjzPPd3HSbKZVbOl +i8NAvfI8B+il5bfXZoNt4Ml/yj+SPiXqWbMsoY9NfXoCt0g1yt+KHNicmcgnTkFmZqbyvu4y3h VcQOzftLJbs2Wu3DQkpRR/KvINm3vNF8UUW2GBNKZw8jY= X-Received: by 2002:a05:6512:3d1c:b0:5aa:2a30:217a with SMTP id 2adb3069b0e04-5aa594a573bmr325607e87.34.1780037299072; Thu, 28 May 2026 23:48:19 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5aa5b79f04dsm72147e87.83.2026.05.28.23.48.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 23:48:17 -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 v6 0/2] drm/amdgpu: fix recursive ww_mutex in devcoredump IB dump Date: Fri, 29 May 2026 11:47:37 +0500 Message-ID: <20260529064740.25060-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260521150841.20625-1-mikhail.v.gavrilov@gmail.com> References: <20260521150841.20625-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. (Reviewed-by Christian on v5.) 2/2 Move the IB dumping into a separate helper that locks 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/ v5: https://lore.kernel.org/amd-gfx/20260521150841.20625-1-mikhail.v.gavrilov@gmail.com/ Changes since v5 (all in patch 2, per Christian's review): - Trim the commit message: drop the reproducer paragraph, keep the problem description and the solution. - Move the IB dumping out of amdgpu_devcoredump_format() into a separate amdgpu_devcoredump_print_ibs() helper. - Use goto error handling inside drm_exec_until_all_locked() instead of break, and drop the now-superfluous `locked` variable. drm_exec_fini() is called once at the end of the helper, not in the locking path. - Patch 1 is unchanged from v5 and keeps Christian's Reviewed-by. A note on one review point I couldn't fully confirm before respinning (asked on the v5 thread [1], no reply yet): in the locking loop, when amdgpu_vm_bo_lookup_mapping() returns no mapping for an IB, this version treats it as non-fatal -- there is simply nothing to lock for that IB, so the loop continues, and the content loop still emits the "IB #N " header without a body. goto-abort is reserved for real errors (VM not found, drm_exec_lock_obj() failure). If a missing mapping should instead abort the whole dump, I'll change it. [1] https://lore.kernel.org/amd-gfx/CABXGCsPPY3qX7Ad-a7==nmA5R7aejCTCrmWYpn-9OQQU=1eMMA@mail.gmail.com/ Changes since v4: - Pass nr=1 to drm_exec_init() in amdgpu_vm_handle_fault() (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(); drop the root output parameter; unlock with drm_exec_unlock_obj() on the VM-recheck-failed path (Christian). - Resolves the docutils warning the kernel test robot reported on v3. Changes since v2: - Reworked along the lines Christian suggested: amdgpu_vm_lock_by_pasid() takes a drm_exec context directly (patch 1), devcoredump locks the root PD and all IB BOs in one ticket (patch 2). The v2 helper struct and the three collect/lock/release helpers 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 | 215 ++++++++++-------- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 91 +++++--- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- 3 files changed, 184 insertions(+), 124 deletions(-) -- 2.54.0