linux-next: test failure after merge of the mm-nonmm-unstable tree
Mark Brown
maintainerHi all,
After merging the mm-nonmm-unstable tree, today's linux-next testing (arm64 kunit) failed like this:
$ qemu-system-aarch64 -nodefaults -m 1024 -kernel /tmp/next/arm64_kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -machine virt -cpu max [11:39:24] ============================================================ [11:39:24] ======== smp-cond-load-relaxed-timeout (3 subtests) ======== [11:39:24] # smp_cond_relaxed_timeout_succeeds: EXPECTATION FAILED at lib/tests/barrier-timeout-test.c:69 [11:39:24] Expected runtime <= timeout_ns == succeeds, but [11:39:24] runtime <= timeout_ns == 0 (0x0) [11:39:24] succeeds == 1 (0x1) [11:39:24] [FAILED] smp_cond_relaxed_timeout_succeeds [11:39:24] # module: barrier_timeout_test [11:39:24] # smp-cond-load-relaxed-timeout: pass:2 fail:1 skip:0 total:3 [11:39:24] # Totals: pass:2 fail:1 skip:0 total:3 [11:39:24] ========== [FAILED] smp-cond-load-relaxed-timeout ========== [11:39:24] ============================================================ [11:39:24] Testing complete. Ran 9436 tests: passed: 9315, failed: 1, skipped: 120 [11:39:24] Failures: smp-cond-load-relaxed-timeout.smp_cond_relaxed_timeout_succeeds [11:39:24] Test results stored in /tmp/next/arm64_kunit.json [11:39:24] Elapsed time: 121.367s total, 0.002s configuring, 63.737s building, 57.613s running
Note that we are running on an arm64 host with access to KVM so the above should be running with KVM rather than being emulated.
Caused by commit
0403c34571d1d (kunit: add tests for smp_cond_load_relaxed_timeout())
in that it's adding the new test which fails, I didn't investigate the quality of the test. I do note that there's some related functional work also from Ankur that's also added by the mm-nonmm-unstable tree but didn't investigate that either.
I have used the version from next-20260506 instead, the code was in next-20260508 but I belive Thierry was emulating.
Mark Brown
maintainerQuoted 12 lines · Mark Brown
After merging the mm-nonmm-unstable tree, today's linux-next testing (arm64 kunit) failed like this:
[11:39:24] Failures: smp-cond-load-relaxed-timeout.smp_cond_relaxed_timeout_succeeds
Note that we are running on an arm64 host with access to KVM so the above should be running with KVM rather than being emulated.
Caused by commit
0403c34571d1d (kunit: add tests for smp_cond_load_relaxed_timeout())
Quoted 7 lines
in that it's adding the new test which fails, I didn't investigate the quality of the test. I do note that there's some related functional work also from Ankur that's also added by the mm-nonmm-unstable tree but didn't investigate that either.
I have used the version from next-20260506 instead, the code was in next-20260508 but I belive Thierry was emulating.
Actually these patches were introduced in next-20260427 so I'll need to go back to next-20260424 instead, sorry (got confused by the tree rebasing). It looks like something in the more recent versions made the issue more promienent.
Quoted 19 lines · Mark Brown
Quoted 16 lines · Mark Brown
After merging the mm-nonmm-unstable tree, today's linux-next testing (arm64 kunit) failed like this:
[11:39:24] Failures: smp-cond-load-relaxed-timeout.smp_cond_relaxed_timeout_succeeds
Note that we are running on an arm64 host with access to KVM so the above should be running with KVM rather than being emulated.
Caused by commit
0403c34571d1d (kunit: add tests for smp_cond_load_relaxed_timeout())in that it's adding the new test which fails, I didn't investigate the quality of the test. I do note that there's some related functional work also from Ankur that's also added by the mm-nonmm-unstable tree but didn't investigate that either.
Quoted 7 lines
Quoted 2 lines
I have used the version from next-20260506 instead, the code was in next-20260508 but I belive Thierry was emulating.
Actually these patches were introduced in next-20260427 so I'll need to go back to next-20260424 instead, sorry (got confused by the tree rebasing). It looks like something in the more recent versions made the issue more promienent.
Hi Mark
Thanks for the report. The failing test case is using a kthread to toggle a bit which the test depends on.
The first test condition succeeds:
KUNIT_EXPECT_EQ(test, (bool)(result & TEST_FLAG_VAL), succeeds)
so the bit did get toggled. The second condition (runtime <= timeout_ns) failed:
KUNIT_EXPECT_EQ(test, runtime <= timeout_ns, succeeds)
Possibly because the we got scheduled out while running the test. Not sure why the test started failing now. I'm guessing the VM running the test isn't under CPU stress and the like.
If that can happen then I should relax the second condition.
--
ankur
Quoted 41 lines · Ankur Arora
Quoted 19 lines · Mark Brown
Quoted 16 lines · Mark Brown
After merging the mm-nonmm-unstable tree, today's linux-next testing (arm64 kunit) failed like this:
[11:39:24] Failures: smp-cond-load-relaxed-timeout.smp_cond_relaxed_timeout_succeeds
Note that we are running on an arm64 host with access to KVM so the above should be running with KVM rather than being emulated.
Caused by commit
0403c34571d1d (kunit: add tests for smp_cond_load_relaxed_timeout())in that it's adding the new test which fails, I didn't investigate the quality of the test. I do note that there's some related functional work also from Ankur that's also added by the mm-nonmm-unstable tree but didn't investigate that either.
Quoted 7 lines
Quoted 2 lines
I have used the version from next-20260506 instead, the code was in next-20260508 but I belive Thierry was emulating.
Actually these patches were introduced in next-20260427 so I'll need to go back to next-20260424 instead, sorry (got confused by the tree rebasing). It looks like something in the more recent versions made the issue more promienent.
Hi Mark
Thanks for the report. The failing test case is using a kthread to toggle a bit which the test depends on.
The first test condition succeeds:
KUNIT_EXPECT_EQ(test, (bool)(result & TEST_FLAG_VAL), succeeds)so the bit did get toggled. The second condition (runtime <=
timeout_ns) failed:
Quoted 7 lines
KUNIT_EXPECT_EQ(test, runtime <= timeout_ns, succeeds)Possibly because the we got scheduled out while running the test. Not sure why the test started failing now. I'm guessing the VM running the test isn't under CPU stress and the like.
If that can happen then I should relax the second condition.
Thinking some more, the condition is much too strict.
Instead of:
succeeds => (runtime <= timeout_ns)
A better check would be:
!succeeds => runtime >= timeout_ns
I'll send a patch to that effect.
Thanks
--
ankur
Mark Brown
maintainerQuoted 9 lines · Ankur Arora
Quoted 8 lines · Ankur Arora
Quoted 2 lines · Mark Brown
Quoted 2 lines
Note that we are running on an arm64 host with access to KVM so the above should be running with KVM rather than being emulated.
Possibly because the we got scheduled out while running the test. Not sure why the test started failing now. I'm guessing the VM running the test isn't under CPU stress and the like.
Yes, the system should be doing nothing except run KUnit and any random background stuff, it's pretty high end so any background stuff shouldn't need to disturb KUnit. At some point I will go back to running multiple tests in parallel but didn't do that yet.
As I indicated above I'm fairly sure the main difference is that I'm running on actual hardware not emulation, though I do think there's something else that made it more prominent in that situation. I'm fairly sure Thierry was using emulation while he was running -next.
Quoted 11 lines
Quoted 1 line
If that can happen then I should relax the second condition.
Thinking some more, the condition is much too strict.
Instead of:
succeeds => (runtime <=timeout_ns)A better check would be:
!succeeds => runtime >=timeout_nsI'll send a patch to that effect.
Hopefully that's it...