[PATCH] elf: Fix elf/tst-decorate-maps on aarch64 after 321e1fc73f

[Dev Jain]

On 18/12/25 6:38 pm, Adhemerval Zanella Netto wrote:
>
> On 18/12/25 10:05, Dev Jain wrote:
>> On 18/12/25 5:56 pm, Adhemerval Zanella Netto wrote:
>>> On 18/12/25 03:27, Dev Jain wrote:
>>>> On 18/12/25 2:25 am, Adhemerval Zanella wrote:
>>>>> The malloc size might be too low to trigger the mmap call on aarch64
>>>>> with mTHP.
>>>> Thanks, but mTHP has got nothing to do with mmap() getting triggered by
>>>> malloc() - it is dependent on MMAP_THRESHOLD? I think we can have this
>>>> change when we get around changing the hardcoded tunables according
>>>> to whether THP is there by default or not - we definitely should
>>>> increase MMAP_THRESHOLD in that case.
>>> The test is issued with
>>>
>>> tst-decorate-maps-ENV = \
>>>   GLIBC_TUNABLES=glibc.malloc.arena_max=8:glibc.malloc.mmap_threshold=1024:glibc.mem.decorate_maps=1
>>> tst-decorate-maps-ARGS = 8
>> So currently we do xmalloc (256 * 1024), which is greater than glibc.malloc.mmap_threshold=1024,
>> so mmap gets triggered right? If you are trying to say that this size is not enough to back the returned
>> memory with a 2MB THP - why is it necessary for this test?
> It is necessary because this test check is the __set_vma_name is correctly
> setting the mmap range used by sysmalloc_mmap. Currently after 321e1fc73f
> on 4k page size system tst-decorate-maps fails because there is no decoration
> found because the memory is being allocated in the sbrk range.

Ah I get you now. So basically a malloc(256KB) gets satisfied from the brk heap itself
because it is getting extended by 2MB straightaway. Thanks.

Would you be so kind to include this in the patch description - that the test now fails
because it expects malloc() to go to mmapped memory but post my commit will be
satisfied from the brk heap itself? It is not obvious to figure that out!