Claude review: bug/kunit: Core support for suppressing warning backtraces

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**test-bug.h changes — Good:**

The `kunit_is_suppressed_warning()` inline correctly gates on the existing `kunit_running` static branch before dereferencing the hook pointer:

```c
static inline bool kunit_is_suppressed_warning(bool count)
{
	if (!static_branch_unlikely(&kunit_running))
		return false;

	return kunit_hooks.is_suppressed_warning &&
	       kunit_hooks.is_suppressed_warning(count);
}
```

The NULL-check on `kunit_hooks.is_suppressed_warning` before calling is important for the window between kunit_running being enabled and hooks being installed. The `#include <linux/types.h>` for `bool` is the right fix for `CONFIG_KUNIT=n` builds.

**kernel/panic.c changes — Good:**

```c
if (kunit_is_suppressed_warning(true)) {
	warn_rcu_exit(rcu);
	return;
}
```

In `warn_slowpath_fmt()`, the check with `count=true` is placed after `warn_rcu_enter()` and correctly exits via `warn_rcu_exit()` before returning. Same pattern in `__warn_printk()` but with `count=false` to avoid double-counting. This is correct — on architectures with `__WARN_FLAGS`, both `__warn_printk()` and `__report_bug()` fire for the same warning; counting only in `__report_bug()` ensures one increment per warning.

**lib/bug.c changes — Correct but worth noting:**

```c
#ifdef CONFIG_KUNIT
	if (warning && kunit_is_suppressed_warning(true))
		return BUG_TRAP_TYPE_WARN;
#endif

	disable_trace_on_warning();
```

The `disable_trace_on_warning()` is moved after the suppression check, which means suppressed warnings won't disable tracing. This is the right behavior — suppressed warnings should have zero side effects. The `#ifdef CONFIG_KUNIT` guard avoids a function call in non-KUnit builds.

Placing the check before the `once` logic is correct: suppressed WARN_ON_ONCE() calls don't consume the single-fire budget, so they remain armed for non-test contexts.

**bug.c (new file) — Minor observations:**

The `synchronize_rcu()` in `kunit_suppress_warning_remove()` is correct to ensure no readers see a stale pointer, but it means removal is a blocking call. This is fine for test teardown paths but means `kunit_end_suppress_warning()` (which calls `kunit_release_action()` → `kunit_suppress_warning_remove()`) blocks on a grace period. In test contexts this is acceptable.

The `__kunit_is_suppressed_warning_impl()` function:
```c
bool __kunit_is_suppressed_warning_impl(bool count)
{
	guard(rcu)();
	list_for_each_entry_rcu(w, &suppressed_warnings, node) {
		if (w->task == current) {
			if (count)
				atomic_inc(&w->counter);
			return true;
		}
	}
	return false;
}
```

This is called from `__warn_printk()` which can be in `noinstr` context on some architectures. The cover letter mentions this was addressed ("Made __kunit_is_suppressed_warning nice to noinstr functions"), but the static branch check in the inline wrapper ensures this function is only reached when KUnit is running, which won't happen in early boot noinstr paths. The `guard(rcu)()` use is clean.

**One subtle issue:** `kunit_start_suppress_warning()` calls `kunit_has_active_suppress_warning()` which calls `__kunit_is_suppressed_warning_impl(false)`. This does an RCU-protected list walk to check if suppression is active for `current`. But the caller hasn't taken any locks for the list yet — this is fine because the check is inherently racy (the list could change between check and `list_add_rcu()`), but since all calls are from the same kthread and suppression is per-task, no other thread would be adding entries for our task. So the check-then-act pattern is safe here.

---
Generated by Claude Code Patch Reviewer