[PATCH v8 1/4] bug/kunit: Core support for suppressing warning backtraces

[David Gow]

Le 08/05/2026 à 14:52, Albert Esteve a écrit :
> On Wed, May 6, 2026 at 12:11 PM Albert Esteve <aesteve at redhat.com> wrote:
>>
>> On Wed, May 6, 2026 at 11:40 AM David Gow <david at davidgow.net> wrote:
>>>
>>> Le 04/05/2026 à 3:41 PM, Albert Esteve a écrit :
>>>> From: Alessandro Carminati <acarmina at redhat.com>
>>>>
>>>> Some unit tests intentionally trigger warning backtraces by passing bad
>>>> parameters to kernel API functions. Such unit tests typically check the
>>>> return value from such calls, not the existence of the warning backtrace.
>>>>
>>>> Such intentionally generated warning backtraces are neither desirable
>>>> nor useful for a number of reasons:
>>>> - They can result in overlooked real problems.
>>>> - A warning that suddenly starts to show up in unit tests needs to be
>>>>     investigated and has to be marked to be ignored, for example by
>>>>     adjusting filter scripts. Such filters are ad hoc because there is
>>>>     no real standard format for warnings. On top of that, such filter
>>>>     scripts would require constant maintenance.
>>>>
>>>> Solve the problem by providing a means to suppress warning backtraces
>>>> originating from the current kthread while executing test code. Since
>>>> each KUnit test runs in its own kthread, this effectively scopes
>>>> suppression to the test that enabled it. Limit changes to generic code
>>>> to the absolute minimum.
>>>>
>>>> Implementation details:
>>>> Suppression is integrated into the existing KUnit hooks infrastructure
>>>> in test-bug.h, reusing the kunit_running static branch for zero
>>>> overhead when no tests are running.
>>>>
>>>> Suppression is checked at three points in the warning path:
>>>> - In warn_slowpath_fmt(), the check runs before any output, fully
>>>>     suppressing both message and backtrace. This covers architectures
>>>>     without __WARN_FLAGS.
>>>> - In __warn_printk(), the check suppresses the warning message text.
>>>>     This covers architectures that define __WARN_FLAGS but not their own
>>>>     __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where
>>>>     the message is printed before the trap enters __report_bug().
>>>> - In __report_bug(), the check runs before __warn() is called,
>>>>     suppressing the backtrace and stack dump.
>>>>
>>>> To avoid double-counting on architectures where both __warn_printk()
>>>> and __report_bug() run for the same warning, kunit_is_suppressed_warning()
>>>> takes a bool parameter: true to increment the suppression counter
>>>> (used in warn_slowpath_fmt and __report_bug), false to check only
>>>> (used in __warn_printk).
>>>>
>>>> The suppression state is dynamically allocated via kunit_kzalloc() and
>>>> tied to the KUnit test lifecycle via kunit_add_action(), ensuring
>>>> automatic cleanup at test exit. Writer-side access to the global
>>>> suppression list is serialized with a spinlock; readers use RCU.
>>>>
>>>> Three API forms are provided:
>>>> - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for
>>>>     automatic teardown on scope exit, kunit_add_action() as safety net
>>>>     for abnormal exits (e.g. kthread_exit from failed assertions).
>>>>     Suppression handle is only accessible inside the block.
>>>> - KUNIT_START/END_SUPPRESSED_WARNING(test): manual macros for larger
>>>>     blocks or when warning counts need to be checked after suppression
>>>>     ends. Limited to one pair per scope.
>>>> - kunit_start/end_suppress_warning(test): direct functions returning
>>>>     an explicit handle, for retaining the handle within the test,
>>>>     or for cross-function usage.
>>>>
>>>> Signed-off-by: Guenter Roeck <linux at roeck-us.net>
>>>> Signed-off-by: Alessandro Carminati <acarmina at redhat.com>
>>>> Reviewed-by: Kees Cook <kees at kernel.org>
>>>> Signed-off-by: Albert Esteve <aesteve at redhat.com>
>>>> ---
>>>
>>> This looks pretty good to me, thanks.
>>>
>>> Reviewed-by: David Gow <david at davidgow.net>
>>>
>>> It's maybe slightly over-the-top to now have three different ways of
>>> enabling warning suppression: I'd probably personally get rid of
>>> KUNIT_START/END_SUPPRESSED_WARNING() if we had to lose one. But if
>>> there's a real reason to prefer keeping all three, it's not actually a
>>> problem to do so.
>>
>> Thanks for the review!
>>
>> I think the three forms earn their keep: the scoped form is the go-to
>> for most cases, but the macros avoid indentation without requiring
>> users to manage a raw pointer. I initially removed the macros and
>> added them back later. Direct calls to the functions will be less
>> frequent, used only when you need the handle.
>>
>> That said, if it becomes a maintenance burden, the macros are the
>> easiest to drop since they're thin wrappers. Let me know if you prefer
>> them to be dropped, and I will send a v9 with that and the
>> `KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT` additions to the drm test
>> patch.
>>
>> BR,
>> Albert.
>>
>>>
>>> Regardless, this series is looking pretty ready to me. Let me know if
>>> you're planning a v9, otherwise we'll take this when you're ready.
> 
> I have been thinking, and despite my last response arguing against it,
> I think I will send that v9 and remove
> KUNIT_START/END_SUPPRESSED_WARNING(). Since the scoped approach with a
> reduced extent should be the default style for most cases, the direct
> calls can cover any other use cases without needing macros. Plus,
> since macros set the handler name for you, it seems odd not to be able
> to use them more than once per test.

Yeah, that was a part of my thought: all of the possible uses of 
KUNIT_START/END_SUPPRESSED_WARNING() can be replaced with the scoped 
version except for the one case where you want to check the number of 
warnings specifically after the scope. I'm not sure the latter would be 
common, and in the few places it's useful, the direct calls are not 
_that_ much more difficult to use.

> I hope that's ok. After that I think it should be ready (at least from my side).
> 
Sounds good: assuming no last-minute disasters, we'll take v9 then.

Cheers,
-- David