On 10/14/26 12:12, Olivier Kaloudoff wrote: > Hi Christian, > >> Yeah and you need to fix the fence orphaning and *NOT* the wait! > > Agreed — found the exact orphan site. drm_sched_entity_push_job() > pushes the job onto entity->job_queue first, then > drm_sched_rq_add_entity() sees entity->stopped (under entity->lock) > and returns NULL: the scheduler is never woken, the job strands on > the spsc queue, and its fence never signals. In our repro the dying > process's fault path submits the migration job on its own killed > entity — it's the process-kill race, not a device-unplug race at > all, which is why drm_dev_enter() doesn't cover it. > > This is the same failure Tong Liu reported in August 2025 (task > hang after job submission during process kill); that fix was > rejected for checking entity->stopped without the lock. The clean > fix is not to pre-check but to handle the NULL return while still > under entity->lock: drain the queue / schedule the kill-jobs work > so each stranded job's finished fence completes with -ESRCH. > >> Blocking for all fences is correct shutdown order. > > Agreed. v7 drops the timeout entirely — unbounded wait restored. > With fences guaranteed to signal, the copy_done error path becomes > genuinely reachable via the fence's error status, so the error > propagation and migrate->dst rollback Felix asked for stay — now > on a real error path instead of a timeout. > > v7 is now implemented and tested on this machine (7.3.0-rc5 + > p1/p2 teardown+restore-stop, sched orphan fix, KFD fence-error > rework). Hot-unplug test: svmhog2 mid-migration + a second KFD > process, then Thunderbolt deauthorize. With only the sched fix > the host still wedges — the kill-jobs drain prevents the orphan, > but the unplug path additionally needs the KFD teardown ordering > (processes torn down before device early-fini) and the restore > worker stopping on -ENODEV. With the full stack: fences complete > with error instead of orphaning, both KFD processes get SIGBUS > and reap cleanly, device tears down, host stays alive, and > re-authorizing gives a clean re-enumeration. So your direction > was right — the wait was never the bug — but the orphan fix is > necessary rather than sufficient for unplug. > > One question on layering: the push-to-killed-entity fix belongs to > drm/sched, which is dri-devel/drm-misc territory — do you want it > as a standalone patch there, or kept in this series? I can also > guard the KFD submit side so it doesn't push to a stopped entity > in the first place, but the sched-side drain is the airtight fix > since entity kill can always race a locked pre-check.
No that is another race in amdgpu and is not related to the scheduler at all. entity->stopped should only be set to false *after* all potential users are gone because that potentially also frees up the scheduler. Otherwise we run into tons of other race conditions with scheduler submission and teardown. In the case of a hot remove the run_job callback should recognize that the device is gone and return an error, which is then bubbled up into the dma_fence again. The warning from the scheduler is just pointing out that amdgpu is doing something very nasty here. Regards, Christian. > > Regards, > Olivier
