On Thu, 13 Mar 2025 at 19:44, Alessandro Carminati acarmina@redhat.com wrote:
From: Guenter Roeck linux@roeck-us.net
Some unit tests intentionally trigger warning backtraces by passing bad parameters to API functions. Such unit tests typically check the return value from those 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. Since the new functionality results in an image size increase of about 1% if CONFIG_KUNIT is enabled, provide configuration option KUNIT_SUPPRESS_BACKTRACE to be able to disable the new functionality. This option is by default enabled since almost all systems with CONFIG_KUNIT enabled will want to benefit from it.
Cc: Dan Carpenter dan.carpenter@linaro.org Cc: Daniel Diaz daniel.diaz@linaro.org Cc: Naresh Kamboju naresh.kamboju@linaro.org Cc: Kees Cook keescook@chromium.org Tested-by: Linux Kernel Functional Testing lkft@linaro.org Acked-by: Dan Carpenter dan.carpenter@linaro.org Reviewed-by: Kees Cook keescook@chromium.org Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Alessandro Carminati acarmina@redhat.com
Thanks Guenter & Alessandro: I'm very happy with this.
Reviewed-by: David Gow davidgow@google.com
-- David