linux-kernel - Re: [PATCH v5 1/5] bug/kunit: Core 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-vegan-lumpy-marmoset-488b6a@houat>
Date: Mon, 2 Jun 2025 12:38:10 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Kees Cook <kees@...nel.org>, 
	Alessandro Carminati <acarmina@...hat.com>, linux-kselftest@...r.kernel.org, 
	Dan Carpenter <dan.carpenter@...aro.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>, 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, 
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning
 backtraces

On Mon, Jun 02, 2025 at 09:57:07AM +0200, Peter Zijlstra wrote:
> On Sat, May 31, 2025 at 06:51:50AM -0700, Kees Cook wrote:
> 
> > It's not for you, then. :) I can't operate ftrace, but I use kunit
> > almost daily. Ignoring WARNs makes this much nicer, and especially for
> > CIs.
> 
> I'm thinking you are more than capable of ignoring WARNs too. This
> leaves the CI thing.
> 
> So all this is really about telling CIs which WARNs are to be ignored,
> and which are not? Surely the easiest way to achieve that is by
> printing more/better identifying information instead of suppressing
> things?

You might also want to test that the warn is indeed emitted, and it not
being emitted result in a test failure.

And I can see a future where we would fail a test that would trigger an
unexpected WARN.

Doing either, or none, would be pretty terrible UX for !CI users too.
How on earth would you know if the hundreds of WARN you got from the
tests output are legitimate or not, and if you introduced new ones
you're supposed to fix?

Maxime

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