On 10/13/26 20:53, 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
>
> 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.
Yeah and you need to fix the fence orphaning and *NOT* the wait!
>
>> 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.
Yes and that is completely intentional and mandatory!
Blocking for all fences is correct shutdown order. What is not correct is that
the fences never signals.
There must be some problem with the error handling in the SDMA submission code.
> This is also the shape Felix asked
> for — guard HW access with dev_enter/exit and keep no unbounded
> fence waits inside those sections.
Clear NAK to that!
Regards,
Christian.
>
> 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.
>
> Regards,
> Olivier
