Linux kernel amdgpu: recursive reservation lock in devcoredump can self-deadlock the coredump worker

Impact

When a job hangs, amdgpu_devcoredump_format() takes the VM root page directory's dma_resv via amdgpu_vm_lock_by_pasid() and then calls amdgpu_bo_reserve() on each IB buffer object, with no ww_acquire ticket shared between them. If an IB BO shares its dma_resv with the root PD - the always-valid case - the second acquire blocks on a lock the same worker already holds, wedging the events_unbound kernel worker that runs the deferred coredump. On a shared AMD GPU node this path is reached by any tenant whose job times out the engine, and a stuck kernel worker is not something an operator can clear without taking the node out of service. With amdgpu.gpu_recovery=0 the timeout handler refires roughly every two seconds and each pass emits a lockdep splat, drowning the kernel ring buffer and any logging that depends on it. In the trace quoted in the fix the two reservations are on different BOs, so what was observed there is the lockdep warning; the self-deadlock is the case the patch describes as real. The fix also removes a BO refcount leak on the amdgpu_bo_reserve() failure path.

Who can reach it

Local. Any tenant holding a GPU context on the node - an open amdgpu render node is enough, no elevated privilege - who can submit work that hangs the engine. No remote path.

What to do

Move to a stable kernel carrying one of the two linked commits. The amdgpu module cannot be unloaded while GPU workloads hold it, so in practice this means draining the node and rebooting into the patched kernel. The record names only the stable commits, not a fixed release number, so check your distro kernel's changelog rather than assuming a version.

References

Related entries

• GPU / accelerator firmware (VBIOS, GSP, NVSwitch): GPU-resident firmware sits below the host OS and is not coveredNCVD-0000-012-gpu-accelerator-firmware-vbios-g · GPU / accelerator firmware (VBIOS, GSP, NVSwitch)Unscored
• NVIDIA Multi-Instance GPU (MIG) partitioning: MIG gives each instance its own SM slice, L2 slice, memory slice andNCVD-2020-001-nvidia-multi-instance-gpu-mig-pa · NVIDIA Multi-Instance GPU (MIG) partitioningUnscored
• NVIDIA Multi-Instance GPU (MIG) partitioning: MIG gives each instance its own SM slice, L2 slice, memory slice andNCVD-2020-003-nvidia-multi-instance-gpu-mig-pa · NVIDIA Multi-Instance GPU (MIG) partitioningUnscored
• Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA): GPUs apply data-dependent losslessNCVD-2023-003-integrated-gpu-graphics-data-com · Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA)Unscored
• NVIDIA Confidential Computing (H100/H200/B100/B200/GB200) - CC-DevTools operating mode: NVIDIA GPU confidentialNCVD-2023-004-nvidia-confidential-computing-h1 · NVIDIA Confidential Computing (H100/H200/B100/B200/GB200) - CC-DevTools operating modeUnscored
• Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA): GPUs apply data-dependent losslessNCVD-2023-005-integrated-gpu-graphics-data-com · Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA)Unscored