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

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 <[email protected]>

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/[email protected]?part=1