Re: Failure of func-x86_64-memlock

[Thomas Huth <thuth@redhat.com>]

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