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

Message-ID: <ebd56bdd-db7f-4b12-910f-1151ad8d2659@roeck-us.net>
Date: Mon, 1 Dec 2025 22:01:24 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Brian Norris <briannorris@...omium.org>
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

Hi Brian,

On 12/1/25 20:50, Brian Norris wrote:
> On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
>> On Sun, Nov 30, 2025 at 03:59:17PM -0800, Linus Torvalds wrote:
>> ...
>>> Anyway, *today* the important kernel is the newly minted 6.18 release.
>>> Please do keep testing,
>>>
>>
>> Build results:
>> 	total: 158 pass: 158 fail: 0
>> Qemu test results:
>> 	total: 610 pass: 610 fail: 0
>> Unit test results:
>> 	pass: 666778 fail: 113
>>
>> In terms of testing, that is worse that it sounds. I enabled
>> CONFIG_PM_RUNTIME_KUNIT_TEST last week, and it results in widespread
>> test failures. Picking one (from x86_64):
>>
>> [   34.559694]     # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
>> [   34.559694]     Expected 1 == pm_runtime_barrier(dev), but
>> [   34.559694]         pm_runtime_barrier(dev) == 0 (0x0)
>> [   34.563604]     # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
>>
>> 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.

Guenter