Hi Olivier, looks like my mail from yesterday wasn't send out, so re-sending that again.
Don't be surprised if you receive two messages. On 10/15/26 21:30, Olivier Kaloudoff wrote: > Hi Christian, > >> Fences *must* always signal especially when the device is hot removed. > > Agreed in principle — but the observed failure is precisely the > counter-case. During teardown the dying process's fault path submits > an SDMA job to an already-killed drm_sched entity: > > drm_sched_rq_add_entity: Trying to push to a killed entity Yeah and that needs to be prevented. That is incorrect teardown order in the KFD. When the entity is killed no further submissions to it are possible. > The job never reaches a ring, nothing is left to signal its fence, > and the uninterruptible wait in svm_migrate_copy_done() never > returns. That orphaned fence is what kept the task in D state for > good in the repro. > >> a non interruptible wait with AMDGPU_FENCE_JIFFIES_TIMEOUT can >> never fail. > > The ret < 0 branch is indeed dead code — dropped it in v6, thanks. > > The bound itself is needed for a subtler reason: the wait now runs > inside a drm_dev_enter() critical section, and drm_dev_unplug() > blocks until all such sections exit. An unbounded wait inside the > section would deadlock the unplug path against any fence that fails > to signal, for whatever reason. This is also the shape Felix asked > for — guard HW access with dev_enter/exit and keep no unbounded > fence waits inside those sections. Yeah and that is perfectly correct. drm_dev_unplug() *must* be blocked until all fences are signaled. > If you'd rather guarantee the invariant at the source — i.e. error > out fences orphaned by jobs pushed to an already-killed entity in > drm_sched — happy to look at that too, but it is a much wider change > than the KFD-side guard. 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. Regards, Christian. > > Regards, > Olivier
