Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Calling `drm_sched_fini()` after `drm_sched_init()` fails causes a kernel panic due to uninitialized structures. -- --- Patch [1]: [PATCH 1/2] accel: ethosu: Remove redundant dev_err() --- commit ab2aa317daa0785d0207a88d5d5b51fcef216f77 Author: Pan Chuang <[email protected]> accel: ethosu: Remove redundant dev_err() This commit removes redundant driver-specific error logging after devm_request_threaded_irq(), relying on the core IRQ code to automatically log failures. > diff --git a/drivers/accel/ethosu/ethosu_job.c > b/drivers/accel/ethosu/ethosu_job.c > --- a/drivers/accel/ethosu/ethosu_job.c > +++ b/drivers/accel/ethosu/ethosu_job.c > @@ -338,10 +338,8 @@ int ethosu_job_init(struct ethosu_device *edev) [ ... ] > - if (ret) { > - dev_err(dev, "failed to request irq\n"); > + if (ret) > return ret; > - } > > edev->fence_context = dma_fence_context_alloc(1); [Severity: High] This is a pre-existing issue, but does the error handling path later in ethosu_job_init() cause a kernel panic if drm_sched_init() fails? If drm_sched_init() returns an error (for example, due to an out-of-memory condition), the code jumps to the error label: drivers/accel/ethosu/ethosu_job.c:ethosu_job_init() { ... ret = drm_sched_init(&edev->sched, &args); if (ret) { dev_err(dev, "Failed to create scheduler: %d\n", ret); goto err_sched; } ... err_sched: drm_sched_fini(&edev->sched); return ret; } At this point, the job_scheduled waitqueue inside drm_gpu_scheduler remains completely zero-initialized. When drm_sched_fini() attempts to wake up tasks by calling wake_up_all(&sched->job_scheduled), the zero-initialized list_head means its next pointer is NULL. The list_empty() check incorrectly returns false, and the subsequent list iteration dereferences the NULL pointer. Could this lead to an immediate panic during device probe failures? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
