Failure of func-x86_64-memlock

Failure of func-x86_64-memlock

[Richard Henderson]

Hi guys,

This test has been failing on my laptop for a few weeks.
Any idea why?

There's nothing logged in tests/functional/x86_64/test_memlock*/*,
which itself seems like a bug.


r~

Re: Failure of func-x86_64-memlock

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> Hi guys,
>
> This test has been failing on my laptop for a few weeks.
> Any idea why?
>
> There's nothing logged in tests/functional/x86_64/test_memlock*/*,
> which itself seems like a bug.

I wonder who actually is running the test because:

  @skipLockedMemoryTest(2_097_152)  # 2GB

means it just skips for me on my beefy desktop.

>
>
> r~

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Failure of func-x86_64-memlock

[Thomas Huth]

On 05/09/2025 12.26, Richard Henderson wrote:
> Hi guys,
> 
> This test has been failing on my laptop for a few weeks.
> Any idea why?

FWIW, the test still works for me (after enabling it with "ulimit -l 2097152").

> There's nothing logged in tests/functional/x86_64/test_memlock*/*,
> which itself seems like a bug.

Is there maybe any hint in meson-logs/testlog-thorough.txt instead?

  Thomas

Re: Failure of func-x86_64-memlock

[Richard Henderson]

On 9/8/25 10:12, Thomas Huth wrote:
> On 05/09/2025 12.26, Richard Henderson wrote:
>> Hi guys,
>>
>> This test has been failing on my laptop for a few weeks.
>> Any idea why?
> 
> FWIW, the test still works for me (after enabling it with "ulimit -l 2097152").
> 
>> There's nothing logged in tests/functional/x86_64/test_memlock*/*,
>> which itself seems like a bug.
> 
> Is there maybe any hint in meson-logs/testlog-thorough.txt instead?

Ah, yes, there it is:

TAP version 13
not ok 1 test_memlock.MemlockTest.test_memlock_off
ok 2 test_memlock.MemlockTest.test_memlock_on
ok 3 test_memlock.MemlockTest.test_memlock_onfault
1..3
----------------------------------- stderr -----------------------------------
/home/rth/qemu/src/python/qemu/qmp/legacy.py:89: DeprecationWarning: There is no current 
event loop
   self._aloop = asyncio.get_event_loop()
Traceback (most recent call last):
   File "/home/rth/qemu/src/tests/functional/x86_64/test_memlock.py", line 40, in 
test_memlock_off
     self.assertTrue(status['VmLck'] == 0)
AssertionError: False is not true


So it seems there's some non-zero amount of memory locked in the process, likely nothing 
to do with what we're trying to test, but we're asserting anyway.

Digging into /proc/pic/smaps, I have:

79d7d3547000-79d7d354b000 rw-p 00000000 00:00 0
Size:                 16 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                  16 kB
Pss:                  16 kB
Pss_Dirty:            16 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        16 kB
Referenced:           16 kB
Anonymous:            16 kB
KSM:                   0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
FilePmdMapped:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               16 kB
THPeligible:           0
ProtectionKey:         0
VmFlags: rd wr mr mw me lo ac sd

It's not labeled in /proc/pid/maps, so without more work I don't know where it comes from, 
but *something* in my system libraries has asked for 4 pages of locked memory.


r~

Re: Failure of func-x86_64-memlock

[Thomas Huth]

On 09/09/2025 09.48, Richard Henderson wrote:
> On 9/8/25 10:12, Thomas Huth wrote:
>> On 05/09/2025 12.26, Richard Henderson wrote:
>>> Hi guys,
>>>
>>> This test has been failing on my laptop for a few weeks.
>>> Any idea why?
>>
>> FWIW, the test still works for me (after enabling it with "ulimit -l 
>> 2097152").
>>
>>> There's nothing logged in tests/functional/x86_64/test_memlock*/*,
>>> which itself seems like a bug.
>>
>> Is there maybe any hint in meson-logs/testlog-thorough.txt instead?
> 
> Ah, yes, there it is:
> 
> TAP version 13
> not ok 1 test_memlock.MemlockTest.test_memlock_off
> ok 2 test_memlock.MemlockTest.test_memlock_on
> ok 3 test_memlock.MemlockTest.test_memlock_onfault
> 1..3
> ----------------------------------- stderr -----------------------------------
> /home/rth/qemu/src/python/qemu/qmp/legacy.py:89: DeprecationWarning: There 
> is no current event loop
>    self._aloop = asyncio.get_event_loop()
> Traceback (most recent call last):
>    File "/home/rth/qemu/src/tests/functional/x86_64/test_memlock.py", line 
> 40, in test_memlock_off
>      self.assertTrue(status['VmLck'] == 0)
> AssertionError: False is not true
> 
> 
> So it seems there's some non-zero amount of memory locked in the process, 
> likely nothing to do with what we're trying to test, but we're asserting 
> anyway.
> 
> Digging into /proc/pic/smaps, I have:
> 
> 79d7d3547000-79d7d354b000 rw-p 00000000 00:00 0
> Size:                 16 kB
> KernelPageSize:        4 kB
> MMUPageSize:           4 kB
> Rss:                  16 kB
> Pss:                  16 kB
> Pss_Dirty:            16 kB
> Shared_Clean:          0 kB
> Shared_Dirty:          0 kB
> Private_Clean:         0 kB
> Private_Dirty:        16 kB
> Referenced:           16 kB
> Anonymous:            16 kB
> KSM:                   0 kB
> LazyFree:              0 kB
> AnonHugePages:         0 kB
> ShmemPmdMapped:        0 kB
> FilePmdMapped:         0 kB
> Shared_Hugetlb:        0 kB
> Private_Hugetlb:       0 kB
> Swap:                  0 kB
> SwapPss:               0 kB
> Locked:               16 kB
> THPeligible:           0
> ProtectionKey:         0
> VmFlags: rd wr mr mw me lo ac sd
> 
> It's not labeled in /proc/pid/maps, so without more work I don't know where 
> it comes from, but *something* in my system libraries has asked for 4 pages 
> of locked memory.

Ok, then the easiest fix is likely to allow some few locked pages in that 
assert statement? Care to send a patch?

  Thomas