From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: kunit: Add support for suppressing warning backtraces Date: Sat, 16 May 2026 12:29:13 +1000 Message-ID: In-Reply-To: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com> References: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: kunit: Add support for suppressing warning backtraces Author: Albert Esteve Patches: 6 Reviewed: 2026-05-16T12:29:13.079512 --- This is a well-structured v10 patch series that adds WARN*() backtrace supp= ression to KUnit. The design is sound: it integrates into the existing KUni= t hooks infrastructure for zero overhead when no tests run, uses task-scope= d suppression (leveraging KUnit's kthread-per-test model), and provides bot= h scoped and direct API forms. The series has accumulated Reviewed-by from = David Gow (KUnit maintainer) and Kees Cook, plus testing tags from LKFT. **Strengths:** - Clean integration into existing hooks infrastructure avoids new config op= tions - Task-scoped suppression is simpler and more robust than the earlier funct= ion-name-matching approach - RCU for readers, spinlock for writers is the correct pattern for this use= case - The scoped API using `__cleanup` with `kunit_add_action()` as a safety ne= t is well-thought-out - Good test coverage including cross-kthread isolation test - The `bool count` parameter to avoid double-counting across `__warn_printk= ()` and `__report_bug()` is a necessary detail handled correctly **Concerns (minor):** - The no-nesting restriction (`kunit_has_active_suppress_warning()` check a= t start) is a deliberate simplification but could limit future use cases wh= ere a helper function independently wants suppression - After `kunit_add_action_or_reset()` fails, the entry has already been add= ed to the RCU list via `list_add_rcu()`, so the `_or_reset` suffix handles = cleanup of the `kunit_kzalloc`'d memory, but the list entry was already rem= oved by the reset action =E2=80=94 this is correct but subtle **Overall: This series looks ready to merge. The issues below are minor.** --- --- Generated by Claude Code Patch Reviewer