public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
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

      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