Hi, two small fixes for the KFD teardown path on PCIe surprise removal (e.g. Thunderbolt eGPU link drop), observed on real hardware: an AMD Instinct MI50 eGPU (Razer Core X, TB3) behind which a 19 GB ROCm llama.cpp workload runs 24/7 with several KFD processes live.
Patch 1 fixes a NULL deref + unbounded wait in kgd2kfd_teardown_processes(): on the disconnect path amdgpu_amdkfd_device_fini_sw() frees adev->kfd.dev before amdgpu_device_ip_fini_early() reaches teardown_processes, which then dereferences adev->kfd.dev->kfd_processes_count. We captured the oops in EFI pstore: NULL deref at +0x1b4 in the pciehp removal thread, panic via panic_on_oops. The wait is also unbounded — processes blocked on dead MMIO may never terminate, which wedges pciehp in cond_resched() forever and cascades into hung-task/softlockup panics. Patch 2 stops amdgpu_amdkfd_restore_userptr_worker() from rescheduling itself forever when the device is gone: the VM update paths already fail fast with -ENODEV on unplug (existing drm_dev_enter guards in amdgpu_vm_update_pdes/vm_update_range), but the worker ignores the error code. Observed: ~11k rescheduled restore cycles before the host soft-locked up. Both verified to apply and build against v7.3-rc5; observed and debugged on 7.2.6 with the identical code shape. Pstore traces and the full writeup are in our public repo: https://codeberg.org/kendoulov/linux-gfx906-kernel-patches docs/UPSTREAM-ISSUE-2-unplug-teardown.md These are independent of the KFD SVM evict/restore work — this is the hot-unplug ordering path added by the recent kfd hot-unplug support (6cca686dfce7, d12d05c4bc4c). CCing Xiaogang who has been working in this area. Thanks, Olivier Kaloudoff
