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/i915/selftests: Fix build after dma-fence locking rework Date: Tue, 24 Feb 2026 09:54:10 +1000 Message-ID: In-Reply-To: <20260223172553.1663749-1-matthew.brost@intel.com> References: <20260223172553.1663749-1-matthew.brost@intel.com> <20260223172553.1663749-1-matthew.brost@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The patch replaces direct `fence->lock` access with the new `dma_fence_spinlock()` accessor in two places: > - spin_lock_irq(fence->lock); > + spin_lock_irq(dma_fence_spinlock(fence)); > __list_del_entry(&active->cb.node); > - spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */ > + spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */ This is a straightforward mechanical change. Both the lock and unlock use the same accessor on the same `fence` pointer, so the lock/unlock is properly balanced. The `fence` pointer is non-NULL at this point (guarded by the `if (!fence) return;` above). The commit message accurately describes both the problem and the fix, and correctly identifies the commit that caused the build breakage via the Fixes tag. Christian's question in the review thread about `spin_lock_irq()` vs `spin_lock_irqsave()` is worth noting. Looking at the existing tree, `active_flush()` is called from `i915_active_unlock_wait()` under `rcu_read_lock()`, which does not alter IRQ state. The selftest calling context is process context with interrupts enabled, so `spin_lock_irq()` is technically fine here. But that's a pre-existing design choice, not something this patch introduces or changes. No issues found in this patch. --- Generated by Claude Code Patch Reviewer