linux-kernel - Re: [PATCH v5 0/5] kunit: Add support for suppressing warning backtraces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250602-polar-gray-toucanet-a68a41@houat>
Date: Mon, 2 Jun 2025 12:47:59 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Alessandro Carminati <acarmina@...hat.com>, 
	linux-kselftest@...r.kernel.org, Kees Cook <keescook@...omium.org>, 
	Daniel Diaz <daniel.diaz@...aro.org>, David Gow <davidgow@...gle.com>, 
	Arthur Grillo <arthurgrillo@...eup.net>, Brendan Higgins <brendan.higgins@...ux.dev>, 
	Naresh Kamboju <naresh.kamboju@...aro.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Ville Syrjala <ville.syrjala@...ux.intel.com>, Daniel Vetter <daniel@...ll.ch>, 
	Guenter Roeck <linux@...ck-us.net>, Alessandro Carminati <alessandro.carminati@...il.com>, 
	Jani Nikula <jani.nikula@...el.com>, Jeff Johnson <jeff.johnson@....qualcomm.com>, 
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	Shuah Khan <skhan@...uxfoundation.org>, Linux Kernel Functional Testing <lkft@...aro.org>, 
	dri-devel@...ts.freedesktop.org, kunit-dev@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/5] kunit: Add support for suppressing warning
 backtraces

On Mon, Jun 02, 2025 at 10:24:17AM +0300, Dan Carpenter wrote:
> I like suppressing warning messages but there are still many cases, such
> as mm/kasan/kasan_test_c.c where printing the warning message is the
> whole point.
> 
> We should create a standard way that test bots can filter out deliberate
> errors from unintentional errors.  This would also help humans who have
> to look at test results.
> 
> #define intentional_warning_marker(type) do {				\
> 	pr_err("Triggering intentional %s warning!", type);		\
> } while (0)
> 
> intentional_warning_marker("KASAN");

I understand what your usecase is, and would definitely appreciate
something like that too, but I don't think this is the right way to do
it.

Once we have the basic infrastructure in place to flag which warnings
are legitimate and which aren't, I believe a better way to achieve what
you're asking for would be to treat as failures any warning with a WARN,
and any test expecting a warn that didn't trigger any.

This would bring kunit on par with pretty much every other unit test
frameworks out there, and would make it pretty obvious to any users (CI
and humans) when it works and when it doesn't.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)