From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: bug/kunit: Core support for suppressing warning backtraces
Date: Sat, 16 May 2026 09:36:17 +1000 [thread overview]
Message-ID: <review-patch1-20260515-kunit_add_support-v12-1-a216dc228be8@redhat.com> (raw)
In-Reply-To: <20260515-kunit_add_support-v12-1-a216dc228be8@redhat.com>
Patch Review
**Design and correctness look good.** The hook integration is clean and follows the existing pattern exactly.
**1. Suppression check placement in `__report_bug()` is well-placed:**
```c
+ /*
+ * Before the once logic so suppressed warnings do not consume
+ * the single-fire budget of WARN_ON_ONCE().
+ */
+ if (warning && kunit_is_suppressed_warning(true))
+ return BUG_TRAP_TYPE_WARN;
+
+ disable_trace_on_warning();
```
Good decision to return before both the `once` flag consumption and `disable_trace_on_warning()`. A suppressed warning shouldn't eat the `WARN_ON_ONCE()` budget or disable tracing.
**2. `kunit_start_suppress_warning` uses plain `kzalloc` (not `kunit_kzalloc`):**
```c
+ w = kzalloc(sizeof(*w), GFP_KERNEL);
```
This is correct since the lifetime is manually managed via `call_rcu` -> `kfree`, but it's worth noting the cover letter says "dynamically allocated via kunit_kzalloc()" which is inaccurate — only the overall cover letter, not the patch 1 commit message which correctly says `kzalloc()`.
**3. The `kunit_is_suppressed_warning` inline checks the function pointer before calling:**
```c
+ return kunit_hooks.is_suppressed_warning &&
+ kunit_hooks.is_suppressed_warning(count);
```
This NULL check is correct — the hook may not be installed if the kunit module hasn't loaded yet but `kunit_running` was somehow set. Defensive and appropriate.
**4. `kunit_end_suppress_warning` silently returns on NULL:**
```c
+void kunit_end_suppress_warning(struct kunit *test,
+ struct kunit_suppressed_warning *w)
+{
+ if (!w)
+ return;
+ kunit_release_action(test, kunit_suppress_warning_cleanup, w);
+}
```
This makes the direct API forgiving when `kunit_start_suppress_warning` returned NULL on failure. That's the right choice since `kunit_start_suppress_warning` already calls `KUNIT_FAIL`.
**5. The `__kunit_suppress_auto_cleanup` accesses `(*wp)->test`:**
```c
+void __kunit_suppress_auto_cleanup(struct kunit_suppressed_warning **wp)
+{
+ if (*wp)
+ kunit_end_suppress_warning((*wp)->test, *wp);
+}
```
This is fine — the `__cleanup` attribute fires on scope exit, before the action teardown, so the handle is still valid at this point.
**6. Minor: `__kunit_is_suppressed_warning_impl` is not exported:**
```c
+bool __kunit_is_suppressed_warning_impl(bool count)
+{
```
No `EXPORT_SYMBOL_GPL`. This is correct since it's only called indirectly via the hook function pointer, and `kunit_has_active_suppress_warning()` (which calls it) IS exported. But `kunit_has_active_suppress_warning` is defined in `bug.c` and calls `__kunit_is_suppressed_warning_impl` directly, so they're in the same compilation unit — no export needed.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-05-15 23:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 8:52 [PATCH v12 0/4] kunit: Add support for suppressing warning backtraces Albert Esteve
2026-05-15 8:52 ` [PATCH v12 1/4] bug/kunit: Core " Albert Esteve
2026-05-15 23:36 ` Claude Code Review Bot [this message]
2026-05-15 8:52 ` [PATCH v12 2/4] kunit: Add backtrace suppression self-tests Albert Esteve
2026-05-15 23:36 ` Claude review: " Claude Code Review Bot
2026-05-15 8:52 ` [PATCH v12 3/4] drm: Suppress intentional warning backtraces in scaling unit tests Albert Esteve
2026-05-15 23:36 ` Claude review: " Claude Code Review Bot
2026-05-15 8:52 ` [PATCH v12 4/4] kunit: Add documentation for warning backtrace suppression API Albert Esteve
2026-05-15 23:36 ` Claude review: " Claude Code Review Bot
2026-05-15 11:46 ` [PATCH v12 0/4] kunit: Add support for suppressing warning backtraces Albert Esteve
2026-05-15 23:36 ` Claude review: " Claude Code Review Bot
-- strict thread matches above, loose matches on Subject: below --
2026-05-15 12:29 [PATCH v13 0/4] " Albert Esteve
2026-05-15 12:29 ` [PATCH v13 1/4] bug/kunit: Core " Albert Esteve
2026-05-15 23:18 ` Claude review: " Claude Code Review Bot
2026-05-14 11:06 [PATCH v11 0/4] kunit: Add " Albert Esteve
2026-05-14 11:06 ` [PATCH v11 1/4] bug/kunit: Core " Albert Esteve
2026-05-16 0:56 ` Claude review: " Claude Code Review Bot
2026-05-13 7:30 [PATCH v10 0/4] kunit: Add " Albert Esteve
2026-05-13 7:30 ` [PATCH v10 1/4] bug/kunit: Core " Albert Esteve
2026-05-16 2:29 ` Claude review: " Claude Code Review Bot
2026-05-04 7:41 [PATCH v8 0/4] kunit: Add " Albert Esteve
2026-05-04 7:41 ` [PATCH v8 1/4] bug/kunit: Core " Albert Esteve
2026-05-04 22:33 ` Claude review: " Claude Code Review Bot
2026-04-20 12:28 [PATCH v7 0/5] kunit: Add " Albert Esteve
2026-04-20 12:28 ` [PATCH v7 1/5] bug/kunit: Core " Albert Esteve
2026-04-22 23:52 ` Claude review: " Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260515-kunit_add_support-v12-1-a216dc228be8@redhat.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox