Claude review: kunit: Add backtrace suppression self-tests

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

Patch Review

Good test coverage. Tests both API forms, incremental counting, active-state transitions, and cross-kthread isolation.

**1. `backtrace_suppression_test_multi_scope` accesses handles after cleanup:**

```c
+	sw1 = kunit_start_suppress_warning(test);
+	trigger_backtrace_warn_on();
+	WARN(1, "suppressed by sw1");
+	kunit_end_suppress_warning(test, sw1);
+
+	sw2 = kunit_start_suppress_warning(test);
+	WARN(1, "suppressed by sw2");
+	kunit_end_suppress_warning(test, sw2);
+
+	KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw1), 2);
+	KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw2), 1);
```

After `kunit_end_suppress_warning(test, sw1)`, the cleanup path runs `kunit_suppress_warning_remove(sw1)` which calls `call_rcu(&w->rcu, kunit_suppress_warning_free)`. The `sw1` pointer remains valid because the RCU grace period cannot complete while the current task is still executing without scheduling — so this is safe *in practice*. However, it's a fragile pattern: if someone inserts a `schedule()`, `msleep()`, or even `cond_resched()` between the end calls and the count checks, it becomes a use-after-free. A brief comment here explaining the RCU grace period guarantee would help future maintainers. Alternatively, reading the count *before* calling `kunit_end_suppress_warning` would be more robust.

**2. `cross_kthread_fn` uses busy-loop pattern:**

```c
+	while (!kthread_should_stop())
+		schedule();
```

This was noted in v10's changelog as fixing a use-after-free on kthread exit. The pattern is correct — the thread waits until `kthread_stop()` is called, preventing the stack-allocated `data` from going out of scope before the thread accesses it.

**3. Good use of `noinline` on helper trigger functions:**

```c
+static noinline void trigger_backtrace_warn(void)
+static noinline void trigger_backtrace_warn_on(void)
```

Prevents the compiler from inlining these into the suppression scope, ensuring the warning actually goes through the full WARN path. Good.

---
Generated by Claude Code Patch Reviewer