Hi Christian, > No, what we need to avoid killing the entity while KFD is still > using it! > > That is basically an use after free what you have here, only that > the drm_sched can point that out with a warning instead of > crashing immediately.
The exact "use" we hit is the dying process's own exit fault: SIGBUS -> coredump -> get_dump_page -> do_swap_page -> svm_migrate_to_ram() submits the migration job on the process's own entity after drm_sched_entity_kill() already ran for it. I think we actually need two complementary things rather than a choice between them: b) The scheduler-level guarantee: a job pushed to an entity must have its fence complete. drm_sched_rq_add_entity() returning NULL for a stopped entity leaves the pushed job stranded on the spsc queue forever — that window exists independently of who killed the entity when. My patch closes it atomically under entity->lock: either the entity is live and the job queues normally, or it is stopped and the job goes through kill_jobs_work so its fence completes with -ESRCH. This is a generic scheduler invariant, not a KFD workaround, and it is the only fix demonstrated to prevent the fence-orphan hang. It is also required on surprise removal even with perfect entity lifetime ordering: a job can be pushed while the entity is still live, then the device disappears before the job completes. Fences must still signal — which is exactly your "fences *must* always signal" requirement. a) The KFD-side lifetime ordering you want: don't kill the entity while KFD can still submit. Worth doing, but the boundary is hard to place — the submitter is the dying task's own mm fault path (coredump -> do_swap_page), not a KFD-controlled context, and the "mm can no longer fault on SVM ranges" point is earlier than exit_mmap and not obviously under KFD's teardown control. So my question: is there an existing KFD ordering point that guarantees no further SVM migration submission for a process's mm — for example after MMU-notifier release but before entity kill? If there is, I'll implement (a) there. If not, I'd like to land (b) as the scheduler-level guarantee, and then evaluate whether an additional KFD lifetime ordering is feasible on top. > drm_dev_unplug() *must* be blocked until all fences are signaled. Agreed — the drm_dev_enter/exit submit guard and the unbounded wait stay, and copy_done now propagates dma_fence_error() so a failed copy can never complete as a successful migration. Regards, Olivier
