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: <aS5wCcwpgkS9n67u@google.com>
Date: Mon, 1 Dec 2025 20:50:17 -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 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? :)

But since you pointed out the failure, I *can* induce the failure by
forcing some scheduling delay.

--- a/drivers/base/power/runtime-test.c
+++ b/drivers/base/power/runtime-test.c
@@ -3,6 +3,7 @@
  * Copyright 2025 Google, Inc.
  */

+#include <linux/delay.h>
 #include <linux/cleanup.h>
 #include <linux/pm_runtime.h>
 #include <kunit/device.h>
@@ -174,6 +175,7 @@ static void pm_runtime_error_test(struct kunit *test)
 	KUNIT_EXPECT_TRUE(test, pm_runtime_suspended(dev));

 	KUNIT_EXPECT_EQ(test, 0, pm_runtime_get(dev));
+	msleep(1000);
 	KUNIT_EXPECT_EQ(test, 1, pm_runtime_barrier(dev)); /* resume was pending */
 	pm_runtime_put(dev);
 	pm_runtime_suspend(dev); /* flush the put(), to suspend */

Looking closer at this part of the API, I think checking the return code
of pm_runtime_barrier() is a bad idea, since it's inherently racy, and
there's really no way to control that race. On the plus side, this test
is the only one that does it. So I can probably just go ahead and make
pm_runtime_barrier() a void function, and stop pretending it's part of
the API surface. One fewer weird part of the runtime PM API to think
about...

Maybe I can get around to that tomorrow.

Also CC Rafael while I'm at it.

Thanks for reporting,
Brian