Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] accel: ethosu: wrong TDR and IRQ teardown order in ethosu_job_fini() --
commit 0cd4405bf9fa95eb128e9e0dbd76f0af4d652c5c Author: Rob Herring (Arm) <[email protected]> accel: ethosu: Quiesce jobs before scheduler teardown This commit stops the scheduler workqueue and timeout work, resets the NPU if a job is in flight, and synchronizes the IRQ before calling drm_sched_fini(). It also adds a cancel_job callback so queued jobs are signaled with -ECANCELED during scheduler teardown. > diff --git a/drivers/accel/ethosu/ethosu_job.c > b/drivers/accel/ethosu/ethosu_job.c > index b7faa715b47e4..d418ae7961cff 100644 > --- a/drivers/accel/ethosu/ethosu_job.c > +++ b/drivers/accel/ethosu/ethosu_job.c [ ... ] > @@ -361,6 +373,15 @@ int ethosu_job_init(struct ethosu_device *edev) > > void ethosu_job_fini(struct ethosu_device *dev) > { > + drm_sched_wqueue_stop(&dev->sched); > + cancel_delayed_work_sync(&dev->sched.work_tdr); > + > + if (READ_ONCE(dev->in_flight_job)) { > + WRITE_ONCE(dev->in_flight_job, NULL); > + ethosu_device_reset(dev); > + } > + > + synchronize_irq(dev->irq); > drm_sched_fini(&dev->sched); > } [Severity: High] Could the ordering of drm_sched_wqueue_stop(), cancel_delayed_work_sync(), and IRQ synchronization here allow work_run_job or work_tdr to be re-queued during teardown? First, drm_sched_wqueue_stop() is called before canceling dev->sched.work_tdr. If dev->sched.work_tdr is already executing ethosu_job_timedout() when ethosu_job_fini() starts, cancel_delayed_work_sync() waits for it to finish: drivers/accel/ethosu/ethosu_job.c:ethosu_job_timedout() { ... drm_sched_stop(&dev->sched, bad); WRITE_ONCE(dev->in_flight_job, NULL); /* Proceed with reset now. */ pm_runtime_force_suspend(dev->base.dev); pm_runtime_force_resume(dev->base.dev); /* Restart the scheduler */ drm_sched_start(&dev->sched, 0); return DRM_GPU_SCHED_STAT_RESET; } At the end of ethosu_job_timedout(), drm_sched_start() calls drm_sched_wqueue_start(), which clears sched->pause_submit and queues work_run_job and work_free_job on sched->submit_wq. Once cancel_delayed_work_sync() returns, work_run_job can pop a queued job and call ethosu_job_run() -> ethosu_job_hw_submit(), setting dev->in_flight_job, submitting a new job to the NPU, and re-arming work_tdr via drm_sched_job_begin() concurrently with ethosu_device_reset() and synchronize_irq(). Second, cancel_delayed_work_sync(&dev->sched.work_tdr) runs before ethosu_device_reset() and synchronize_irq(dev->irq). Before the NPU is reset and the IRQ is synchronized, ethosu_job_irq_handler_thread() -> ethosu_job_handle_irq() can still run and handle an error interrupt without checking dev->in_flight_job: drivers/accel/ethosu/ethosu_job.c:ethosu_job_handle_irq() { ... if (status & (STATUS_BUS_STATUS | STATUS_CMD_PARSE_ERR)) { dev_err(dev->base.dev, "Error IRQ - %x\n", status); drm_sched_fault(&dev->sched); return; } ... } Calling drm_sched_fault() schedules dev->sched.work_tdr again after cancel_delayed_work_sync() has already returned. That allows ethosu_job_timedout() to run concurrently with ethosu_device_reset() (where pm_runtime_force_suspend() disables the NPU clocks while ethosu_device_reset() polls MMIO registers and clears SRAM with memset_io()) as well as concurrently with drm_sched_fini(). Note that while a later commit in the series ("accel: ethosu: Keep scheduler after unplug") replaces this with ethosu_job_stop() and calls disable_irq(dev->irq) before cancel_delayed_work_sync(&dev->sched.work_tdr), it still calls drm_sched_wqueue_stop(&dev->sched) before cancel_delayed_work_sync(&dev->sched.work_tdr), which leaves the race where an in-progress ethosu_job_timedout() calls drm_sched_start() and restarts work_run_job and work_free_job. Should the IRQ be disabled or synchronized before canceling work_tdr, and should drm_sched_wqueue_stop() be called after cancel_delayed_work_sync() (or after preventing ethosu_job_timedout() from calling drm_sched_start() during teardown)? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
