mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-08-23 17:46:33 -04:00
2e5268fc45
The job_lock mutex guarded dev->in_flight_job across ethosu_job_run(),
the threaded IRQ handler, and ethosu_job_timedout(). However, the DRM
scheduler already provides most of the serialization required, which
makes this mutex redundant.
Analyzing the different scenarios:
1. run_job() and timedout_job() are mutually exclusive scheduler
callbacks, so the scheduler itself serializes them.
2. run_job() and the IRQ handler are implicitly serialized, but they can
overlap in time: dma_fence_signal() synchronously queues the next
run_job onto submit_wq, and the worker can execute run_job(next) on
another CPU before the IRQ thread finishes. The mutex previously kept
the IRQ's trailing "in_flight_job = NULL" from racing run_job(next)'s
"in_flight_job = next" store.
The handler is now restructured to clear in_flight_job before calling
dma_fence_signal(), so any run_job(next) woken by the signal observes
NULL.
3. timedout_job() and the IRQ handler can also overlap if the hardware
completes the timed-out job near the timeout boundary, since
drm_sched_stop()'s cancel_work_sync() only synchronizes with the
scheduler's workqueue. The IRQ handler saves in_flight_job into a
local with READ_ONCE() before dereferencing ->done_fence, and
run_job()/timedout_job() publish the field with WRITE_ONCE(). This
prevents the compiler from reloading the pointer, and keeps the IRQ
thread operating on the same job for the duration of the handler even
if timedout_job() concurrently clears the field.
Drop the mutex along with its initialization.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20260516144623.2582427-2-mcanal@igalia.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>