Subject: linux-next: test failure after merge of the mm-nonmm-unstable tree

From: Mark Brown <[email-masked]>
Date: Mon, 18 May 2026 13:00:07 +0100

Hi 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.