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

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

[oushixiong1025]

From: Shixiong Ou <oushixiong@kylinos.cn>

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 <oushixiong@kylinos.cn>
---
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")
 			     __field(u64, fence_context)
 			     __field(u64, fence_seqno)
 			     __field(u64, client_id)
-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

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

[Danilo Krummrich]

On Tue Aug 25, 2026 at 12:36 PM CEST, oushixiong1025 wrote:
> From: Shixiong Ou <oushixiong@kylinos.cn>
>
> 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 <oushixiong@kylinos.cn>
> ---
> 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.

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

[Philipp Stanner]

On Tue, 2026-08-25 at 14:02 +0200, Danilo Krummrich wrote:
> 

[…]

> 
> 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.

Strictly speaking we don't allow for the device pointer to be NULL, so
you might be right. However, it actually is only used for creating
debug prints, so…


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

Wouldn't that be the same result as printing "NULL device"?

Many DRM print helpers do the latter already. __drm_dev_vprintk() takes
dev == NULL into account.
So one might argue that making the print-functions all robust against
NULL would be the more consistent thing.


P.

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

[Danilo Krummrich]

On Tue Aug 25, 2026 at 2:11 PM CEST, Philipp Stanner wrote:
> On Tue, 2026-08-25 at 14:02 +0200, Danilo Krummrich wrote:
>> 
>
> […]
>
>> 
>> 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.
>
> Strictly speaking we don't allow for the device pointer to be NULL, so
> you might be right. However, it actually is only used for creating
> debug prints, so…
>
>
>> 
>> Why can't we have the Kunit test create a fake device for this? For instance,
>> this is where struct faux_device becomes useful.
>
> Wouldn't that be the same result as printing "NULL device"?
>
> Many DRM print helpers do the latter already. __drm_dev_vprintk() takes
> dev == NULL into account.
> So one might argue that making the print-functions all robust against
> NULL would be the more consistent thing.

The dev_printk() primitives already do this, but that's not the point. The point
is that a scheduler with a NULL device makes no sense in the first place, so we
shouldn't support it -- especially not when it is just for a Kunit test that can
easily satisfy the API by calling faux_device_create().