From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: dma-buf: Use trace_invoke_##name() at guarded tracepoint call sites Date: Fri, 13 Mar 2026 14:04:53 +1000 Message-ID: In-Reply-To: <20260312150523.2054552-9-vineeth@bitbyteword.org> References: <1e3c2830-765e-4271-89f7-0b6784b37597@efficios.com> <20260312150523.2054552-9-vineeth@bitbyteword.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Simple conversion of 2 call sites in `drivers/dma-buf/dma-fence.c`: - Line 553: `trace_dma_fence_wait_start()` =E2=86=92 `trace_invoke_dma_fenc= e_wait_start()`, guarded by `trace_dma_fence_wait_start_enabled()` =E2=9C= =93 - Line 562: `trace_dma_fence_wait_end()` =E2=86=92 `trace_invoke_dma_fence_= wait_end()`, guarded by `trace_dma_fence_wait_end_enabled()` =E2=9C=93 Both call sites also have explicit `rcu_read_lock()`/`rcu_read_unlock()` ar= ound them. Since `__do_trace_##name()` now uses `guard(srcu_fast_notrace)` = internally (not classic RCU), the existing `rcu_read_lock()` guards are sup= erfluous for the trace call itself but may exist for other reasons (e.g., t= he fence object stability). This is a pre-existing pattern, not introduced = by this patch. No issues with this patch. --- Generated by Claude Code Patch Reviewer