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

[Ankur Arora]

Ankur Arora <ankur.a.arora@xxxxxxxxxx> writes:

> Mark Brown <broonie@xxxxxxxxxx> writes:
>
>> On Mon, May 18, 2026 at 01:00:07PM +0100, Mark Brown wrote:
>>
>>> 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.
>>
>>> 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.

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