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
