From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/v3d: Attach per-fd reset counters to v3d_stats Date: Mon, 09 Mar 2026 08:56:09 +1000 Message-ID: In-Reply-To: <20260306-v3d-reset-locking-improv-v3-5-49864fe00692@igalia.com> References: <20260306-v3d-reset-locking-improv-v3-0-49864fe00692@igalia.com> <20260306-v3d-reset-locking-improv-v3-5-49864fe00692@igalia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Moving the per-fd reset counter into `v3d_stats` is the natural follow-up. Since `v3d_stats` now outlives the fd (via job references), the reset can safely increment the counter through `job->client_stats->reset_counter` without needing the `file_priv` NULL check. Using `atomic_t` for both global and per-fd reset counters is appropriate - they're incremented under `reset_lock` but read without it, so atomics provide the necessary visibility. The `CONTEXT_RESET_COUNTER` ioctl now sums across all queues: ```c args->value = 0; for (enum v3d_queue q = 0; q < V3D_MAX_QUEUES; q++) args->value += atomic_read(&v3d_priv->stats[q]->reset_counter); ``` This is a slight semantic change from the old per-fd single counter: a single GPU reset previously incremented `v3d_priv->reset_counter` once, but now it increments only the specific queue's stats `reset_counter`. Since `v3d_gpu_reset_for_timeout` increments `job->client_stats->reset_counter` (one specific queue), and the ioctl sums all queues, the total should still reflect one increment per reset caused by this fd. This looks correct. The big cleanup in `v3d_postclose` removing the `file_priv` NULL-ing dance is the main simplification goal of the series, and it's well-justified at this point. No issues. --- Generated by Claude Code Patch Reviewer