Hi Felix, > Do we have a sequencing issues? Should kgd2kfd_teardown_processes run > before the KFD dev is destroyed?
Yes — that's exactly what the v3 resend does (patch 1/3): on the pci_dev_is_disconnected() branch, amdgpu_device_fini_hw() now calls amdgpu_amdkfd_teardown_processes() before the early amdgpu_amdkfd_device_fini_sw(), so the drain runs while kfd.dev and kfd_processes_count are still valid. ftrace on the repro confirms the ordering: teardown from fini_hw, count drains, fini_sw ~8s later. > A reference count leak of the kfd_process or the mm_struct could > prevent this from happening. Doesn't look like a leak — the SIGBUS'd process simply never gets to exit. Its own fault path wedges: coredump -> gup -> do_swap_page -> svm_migrate_to_ram submits an SDMA copy to the already-killed sched entity and then svm_migrate_copy_done() waits uninterruptibly on a fence that can never signal, all while holding svms->lock. Exit never completes, the MMU notifier/cleanup path never runs, and the count never drains. Patch 3/3 makes the SVM migration paths return -ENODEV on a gone device; with that, the process dies and the count drains in ~7s on real hardware (MI50 behind TB3, slot power-off). Olivier
