From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: bug/kunit: Reduce runtime impact of warning backtrace suppression Date: Thu, 23 Apr 2026 09:52:26 +1000 Message-ID: In-Reply-To: <20260420-kunit_add_support-v7-2-e8bc6e0f70de@redhat.com> References: <20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com> <20260420-kunit_add_support-v7-2-e8bc6e0f70de@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Atomic counter ordering concern (minor)** ```c + atomic_inc(&suppressed_warnings_cnt); list_add_rcu(&warning->node, &suppressed_warnings); ``` The counter is incremented before the entry is visible in the list. There's a window where `__kunit_is_suppressed_warning()` sees `counter > 0`, enters the RCU traversal, but doesn't find the entry. This is benign (results in a redundant list walk returning false), but the opposite ordering would be more correct: ```c list_add_rcu(&warning->node, &suppressed_warnings); atomic_inc(&suppressed_warnings_cnt); ``` Wait - that ordering would also have a problem: the entry could be found before the counter is incremented, but `__kunit_is_suppressed_warning()` checks the counter first, so the entry would never be reached. The current ordering is actually the correct one for this fast-path optimization. The teardown side is fine: ```c list_del_rcu(&warning->node); synchronize_rcu(); + atomic_dec(&suppressed_warnings_cnt); ``` Decrement after grace period ensures no reader can observe `count == 0` while still seeing the entry. Correct. **Good separation from patch 1** Splitting the optimization into its own patch is the right call for reviewability. --- Generated by Claude Code Patch Reviewer