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

[PATCH] 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>
---
 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] drm/sched: Guard against NULL dev in drm_sched_job trace event

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The `dev_WARN()` macro is called on `sched->dev` without a NULL check, which results in a NULL pointer dereference when `sched->dev` is NULL.
--

--- Patch [1]: [PATCH] drm/sched: Guard against NULL dev in drm_sched_job trace event ---
commit de5fa30e87a362a3ba489dd802b3a479152bf969
Author: Shixiong Ou <oushixiong@kylinos.cn>

drm/sched: Guard against NULL dev in drm_sched_job trace event

This commit fixes a NULL pointer dereference in the drm_sched_job trace
event class. It adds a check for sched->dev before calling dev_name()
since the dev field is optional and left NULL in KUnit tests.

> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> index 261713dd7d5a1..319a3ec54becf 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")

[Severity: High]
This isn't a bug introduced by this patch, but since we are fixing NULL pointer
dereferences for sched->dev when it is omitted by KUnit tests, does a similar
crash happen in drm_sched_can_queue()?

If a job is submitted with credits exceeding sched->credit_limit, we
call dev_WARN() on the same optional sched->dev field:

drivers/gpu/drm/scheduler/sched_main.c:drm_sched_can_queue() {
	...
	if (s_job->credits > sched->credit_limit) {
		dev_WARN(sched->dev,
			 "Jobs may not exceed the credit limit, truncate.\n");
		s_job->credits = sched->credit_limit;
	}
	...
}

Unlike dev_err() or drm_dev_printk() which safely handle a NULL device
pointer by printing '(NULL device *)', dev_WARN() is a macro that expands
to include dev_driver_string(dev) and dev_name(dev). Both of these will
unconditionally dereference the dev pointer, leading to a kernel oops.

Could this dev_WARN() be triggered during testing and cause the same oops?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821084748.543645-1-oushixiong1025@163.com?part=1