linux-kernel - Re: Linux 6.18

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] [day] [month] [year] [list]

Message-ID: <aS9OKLB8MZks_cD9@google.com>
Date: Tue, 2 Dec 2025 12:38:00 -0800
From: Brian Norris <briannorris@...omium.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: Linux 6.18

On Mon, Dec 01, 2025 at 10:01:24PM -0800, Guenter Roeck wrote:
> On 12/1/25 20:50, Brian Norris wrote:
> > On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
> > > Looks like that fails pretty much on every architecture/platform where
> > > it is enabled. Copying the author (Brian) for feedback.
> > 
> > I wonder how you manage to be the one who hits all these problems,
> > because none of the configurations and environments generated by
> > ./tools/testing/kunit/kunit.py seem to hit it naturally. (I tested
> > hundreds of cycles in various configurations with no failures
> > previously, and I still didn't reproduce it today.) Do you make special
> > effort to direct cosmic rays into your test setups while holding an
> > unlucky charm? :)
> > 
> 
> Neither cosmic rays nor unlucky charm needed (or at least so I hope ;-).
> 
> I build the tests into the kernel and run them while booting in qemu.
> Most other testbeds run the tests as module after booting and/or
> on native machines (not in qemu). That makes a significant difference
> in both behavior and timing.

./tools/testing/kunit/kunit.py runs with either user-mode Linux or QEMU,
with tests built into the kernel and run while booting. That sounds
rather similar to what you run. Previously, the main unique thing I
recalled from your test setups was that you run a much wider array of
ARCHes than I can manage. But that doesn't seem relevant, per your
"pretty much every architecture" note.

Obviously, race conditions are a bit environment / luck dependent, but
I'm just surprised that when it *sounds* like we run something similar,
you get near-100% failure, and I get 0%.

*shrug*

Brian