Re: [PATCH 01/14] bug/kunit: Core support for suppressing warning backtraces
Kees Cook <[email protected]>
| Newsgroups | gmane.linux.kernel.cross-arch,gmane.comp.video.dri.devel,gmane.linux.ports.arm.kernel,gmane.linux.documentation,gmane.linux.kernel,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel |
|---|---|
| Message-ID | <202403121500.64A2C02@keescook> |
On Tue, Mar 12, 2024 at 10:02:56AM -0700, Guenter Roeck wrote: > 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. > > Cc: Dan Carpenter <[email protected]> > Cc: Daniel Diaz <[email protected]> > Cc: Naresh Kamboju <[email protected]> > Cc: Kees Cook <[email protected]> > Signed-off-by: Guenter Roeck <[email protected]> Yup, this looks fine to me. Reviewed-by: Kees Cook <[email protected]> -- Kees Cook