Re: [PATCH 00/14] Add support for suppressing warning backtraces

On 3/14/24 06:36, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck <[email protected]> wrote:
>> 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.
>>
>> One option to address problem would be to add messages such as "expected
>> warning backtraces start / end here" to the kernel log.  However, that
>> would again require filter scripts, it might result in missing real
>> problematic warning backtraces triggered while the test is running, and
>> the irrelevant backtrace(s) would still clog the kernel log.
>>
>> Solve the problem by providing a means to identify and suppress specific
>> warning backtraces while executing test code. Support suppressing multiple
>> backtraces while at the same time limiting changes to generic code to the
>> absolute minimum. Architecture specific changes are kept at minimum by
>> retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and
>> CONFIG_KUNIT are enabled.
>>
>> The first patch of the series introduces the necessary infrastructure.
>> The second patch introduces support for counting suppressed backtraces.
>> This capability is used in patch three to implement unit tests.
>> Patch four documents the new API.
>> The next two patches add support for suppressing backtraces in drm_rect
>> and dev_addr_lists unit tests. These patches are intended to serve as
>> examples for the use of the functionality introduced with this series.
>> The remaining patches implement the necessary changes for all
>> architectures with GENERIC_BUG support.
> 
> Thanks for your series!
> 
> I gave it a try on m68k, just running backtrace-suppression-test,
> and that seems to work fine.
> 
>> Design note:
>>    Function pointers are only added to the __bug_table section if both
>>    CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE are enabled to avoid image
>>    size increases if CONFIG_KUNIT=n. There would be some benefits to
>>    adding those pointers all the time (reduced complexity, ability to
>>    display function names in BUG/WARNING messages). That change, if
>>    desired, can be made later.
> 
> Unfortunately this also increases kernel size in the CONFIG_KUNIT=m
> case (ca. 80 KiB for atari_defconfig), making it less attractive to have
> kunit and all tests enabled as modules in my standard kernel.
> 

Good point. Indeed, it does. I wanted to avoid adding a configuration option,
but maybe I should add it after all. How about something like this ?

+config KUNIT_SUPPRESS_BACKTRACE
+       bool "KUnit - Enable backtrace suppression"
+       default y
+       help
+         Enable backtrace suppression for KUnit. If enabled, backtraces
+         generated intentionally by KUnit tests can be suppressed. Disable
+         to reduce kernel image size if image size is more important than
+         suppression of backtraces generated by KUnit tests.
+

Thanks,
Guenter


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv