Re: [PATCH v2] drm/sched: Guard against NULL dev in drm_sched_job trace event

On Tue Aug 25, 2026 at 12:36 PM CEST, oushixiong1025 wrote:
> From: Shixiong Ou <[email protected]>
>
> The drm_sched_job trace event class calls dev_name() on
> sched_job->sched->dev without checking for NULL. Since the
> dev field in drm_sched_init_args is optional (used for
> debugging), a NULL dev causes a kernel oops when the trace
> event fires.
>
> The DRM scheduler KUnit tests do not set the dev field in
> drm_sched_init_args, leaving sched->dev as NULL. This causes
> a NULL pointer dereference when the drm_sched_job trace event
> fires during test execution, as dev_name(NULL) is called.
>
>   Unable to handle kernel NULL pointer dereference at virtual
>   address 0000000000000050
>   Call trace:
>    trace_event_raw_event_drm_sched_job+0x90/0x258
>    __traceiter_drm_sched_job_queue+0x4c/0x78
>    drm_sched_entity_push_job+0x188/0x380
>    drm_sched_basic_entity_cleanup+0xfc/0x240
>    kunit_try_run_case+0x74/0x170
>
> Signed-off-by: Shixiong Ou <[email protected]>
> ---
> v1->v2:
>   Change each line of the message to be within 75 characters
> 	
>  drivers/gpu/drm/scheduler/gpu_scheduler_trace.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> index 261713dd7d5a..319a3ec54bec 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> @@ -61,7 +61,8 @@ DECLARE_EVENT_CLASS(drm_sched_job,
>  			     __string(name, sched_job->sched->name)
>  			     __field(u32, job_count)
>  			     __field(int, hw_job_count)
> -			     __string(dev, dev_name(sched_job->sched->dev))
> +			     __string(dev, sched_job->sched->dev ?
> +				      dev_name(sched_job->sched->dev) : "none")

I don't think that we should make such changes for Kunit tests only; it implies
that a NULL dev now would be a valid value for the scheduler.

Why can't we have the Kunit test create a fake device for this? For instance,
this is where struct faux_device becomes useful.