From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: accel: ethosu: Remove redundant job_lock
Date: Mon, 18 May 2026 16:46:57 +1000 [thread overview]
Message-ID: <review-patch1-20260516144623.2582427-2-mcanal@igalia.com> (raw)
In-Reply-To: <20260516144623.2582427-2-mcanal@igalia.com>
Patch Review
**Commit message quality**: Excellent. The three-scenario analysis is accurate and demonstrates deep understanding of the DRM scheduler's guarantees and the concurrency model.
**Header change** (`ethosu_device.h`):
```c
- /* For in_flight_job and ethosu_job_hw_submit() */
- struct mutex job_lock;
```
Clean removal. The `in_flight_job` field remains but is now protected by `WRITE_ONCE`/`READ_ONCE` + scheduler serialization rather than the mutex.
**`ethosu_job_run()`** (lines 197–198):
```c
WRITE_ONCE(dev->in_flight_job, job);
ethosu_job_hw_submit(dev, job);
```
Correct. `WRITE_ONCE` prevents the compiler from tearing or eliding the store. The subsequent `writel()` in `ethosu_job_hw_submit()` provides a write memory barrier, ensuring the store to `in_flight_job` is globally visible before the HW processes the command and raises an interrupt.
**`ethosu_job_handle_irq()`** (lines 214–218):
```c
job = READ_ONCE(dev->in_flight_job);
if (job) {
WRITE_ONCE(dev->in_flight_job, NULL);
dma_fence_signal(job->done_fence);
}
```
This is the most critical change. Two things to verify:
1. **Ordering of clear-before-signal**: The `WRITE_ONCE(NULL)` must be visible to other CPUs before `dma_fence_signal()` wakes the scheduler. This holds because `dma_fence_signal()` internally acquires a spinlock (`spin_lock_irqsave`), which acts as an acquire barrier — all preceding stores (including the NULL write) are committed before the lock is acquired and before any waiter is woken. So `run_job(next)` on another CPU will observe `in_flight_job == NULL`. **Correct.**
2. **Race with `timedout_job()`**: If `timedout_job()` concurrently clears `in_flight_job`, the IRQ handler's local `job` copy (captured by `READ_ONCE`) remains valid because the job isn't freed until the scheduler calls `free_job`, which can't happen until after `done_fence` is signaled or the scheduler reprocesses the timed-out job. No use-after-free risk. **Correct.**
**`ethosu_job_timedout()`** (line 273):
```c
WRITE_ONCE(dev->in_flight_job, NULL);
```
Called after `drm_sched_stop()`, which synchronizes with the scheduler's workqueue but not with the threaded IRQ handler. The `WRITE_ONCE` ensures the compiler emits a single atomic store. If the IRQ handler has already captured the old pointer via `READ_ONCE`, it operates on its local copy safely (see scenario 3 in the commit message). **Correct.**
**`ethosu_job_init()`** (lines 303–305):
```c
- ret = devm_mutex_init(dev, &edev->job_lock);
- if (ret)
- return ret;
```
Clean removal of initialization code.
**Minor observation**: It might be worth adding a brief comment on `in_flight_job` in the struct definition noting the access protocol (e.g., `/* Written with WRITE_ONCE by run_job/timedout_job, read with READ_ONCE by IRQ handler */`), since the locking is now implicit rather than explicit. But this is optional and a matter of taste — the commit message serves as the permanent record.
**No bugs found. Reviewed-by worthy.**
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-05-18 6:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-16 14:40 [PATCH] accel: ethosu: Remove redundant job_lock Maíra Canal
2026-05-18 6:46 ` Claude review: " Claude Code Review Bot
2026-05-18 6:46 ` Claude Code Review Bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260516144623.2582427-2-mcanal@igalia.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox