On Sun, 2026-09-27 at 21:59 -0400, [email protected] wrote: > From: Vitaly Prosyak <[email protected]> > > The IGT amd_dispatch test exposed a NULL pointer dereference in the > AMDGPU CS submission path when the GPU schedulers were not ready. > > drm_sched_pick_best() returns NULL when every scheduler in an entity's > list is marked not ready. drm_sched_entity_select_rq() then replaces > the entity's existing runqueue with NULL. > > A subsequent drm_sched_job_arm() retains that invalid runqueue. > When AMDGPU CS submission calls drm_sched_entity_push_job(), the > scheduler pointer derived from entity->rq is invalid and the access > to sched->score faults. The reported oops shows the sequence: > > [drm] scheduler comp_1.1.0 is not ready, skipping > [drm] scheduler comp_1.2.0 is not ready, skipping > BUG: kernel NULL pointer dereference, address: 0000000000000268 > RIP: drm_sched_entity_push_job+0x4f/0x2b0 [gpu_sched]
That seems to be the issue that the LLM was hinting at a few weeks ago: https://lore.kernel.org/dri-devel/[email protected]/ > Call Trace: > amdgpu_cs_ioctl+0x1e9e/0x2530 [amdgpu] > > Keep the previously selected runqueue when no ready replacement is > found. This prevents scheduler selection from turning a valid entity > runqueue into NULL; it does not make a stopped scheduler ready or > guarantee that the submitted job will execute. > > Cc: Christian König <[email protected]> > Cc: Alex Deucher <[email protected]> > Cc: Matthew Brost <[email protected]> > Cc: Danilo Krummrich <[email protected]> > Cc: Philipp Stanner <[email protected]> > Signed-off-by: Vitaly Prosyak <[email protected]> > --- > drivers/gpu/drm/scheduler/sched_entity.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > b/drivers/gpu/drm/scheduler/sched_entity.c > index 4ebb513255ed..b11e1dddabd0 100644 > --- a/drivers/gpu/drm/scheduler/sched_entity.c > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > @@ -584,8 +584,8 @@ void drm_sched_entity_select_rq(struct drm_sched_entity > *entity) > > spin_lock(&entity->lock); > sched = drm_sched_pick_best(entity->sched_list, entity->num_sched_list); > - rq = sched ? &sched->rq : NULL; > - if (rq != entity->rq) { > + if (sched && &sched->rq != entity->rq) { > + rq = &sched->rq; I'm not sure if either explicit or implicit "fix" within drm_sched would solve the issue at hand, because the entire "ready" state tracking is actually a responsibility of the driver – AFAIK its existence has to do with AMD GPUs' ring resetting? I had a conversation with Christian about that a while ago; I think we agree that that flag should be carried by the driver in its own data structure. Does amdgpu still modify sched->ready without going through a drm_sched API? A first grep hints at about ~135 places where this might be the case. What I'm especially wondering about is whether different threads participate in handling that state; dealing with the flag is in no way synchronized in drm_sched_init() and drm_sched_fini(). If yes, the proposed fix would likely still be UB. So since this patch seems to stem from a broken test, not an actual bug at a customer, my hope would be that we have some time to fix it and that AMD, thus, can help with reducing drm_sched's tech debt by removing that flag and have amdgpu invoke the scheduler API in the correct order. Thx P.
