Hi Alex,
> Shouldn't this already be handled by commit 1decbf6bb0b4 ("drm/sched:
> Fix entities with 0 rqs.")? That commit adds a entity->rq NULL check
> in drm_sched_entity_flush() and other places as well.
It was — until June. Commit 2df5efb45425 ("drm/sched: Remove redundant
entity->rq initialization and checks") removed exactly that check from
drm_sched_entity_flush() (and the matching ones in
drm_sched_entity_kill() and drm_sched_job_init()), on the grounds that
"entity->rq can now never be NULL". That holds only for entities that
completed drm_sched_entity_init() — the failed-probe path here calls
drm_sched_entity_destroy() on a never-initialized entity, because
amdgpu_device is zeroed and VCE/UVD entity init only runs in the
scheduler-init phase, after the sw_init phase that failed.
Verified on the crashing build (7.3.0-rc5, gpu-sched.ko): there is no
rq test emitted; flush+0x34 is `mov (%rax),%r15` with rax = entity->rq
== NULL — the `sched = entity->rq->sched` deref:
+0x19: mov 0x18(%rdi),%rax ; rax = entity->rq
+0x34: mov (%rax),%r15 ; fault: *rq
So this is a regression introduced by 2df5efb45425 in the 7.3 window —
the same failed-probe teardown was silently safe before it. v2 of the
patch retargets Fixes: accordingly and Cc's Tvrtko and Philipp.
Regards,
Olivier
