Re: Linux 6.18

["Wysocki, Rafael J" <rafael.j.wysocki@intel.com>]

On 12/2/2025 5:50 AM, 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? :)
>
> 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...

Yes, pm_runtime_barrier() should be void, the return value is a leftover 
thing.


> Maybe I can get around to that tomorrow.

I can do it unless you specifically want to take care of it yourself.