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

[Dev Jain]

On 19/12/25 9:42 pm, Adhemerval Zanella Netto wrote:
>
> On 18/12/25 11:31, Dev Jain wrote:
>> 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!
>>
> Right, are you with the following commit message:
>
>   The test check is the __set_vma_name is correctly setting the mmap 
>   range used by sysmalloc_mmap.  Currently after 321e1fc73fon 4k page s
>   ize system tst-decorate-maps fails because there is no decoration
>   found due the memory is being allocated in the sbrk range.

I would prefer this:

The intention of the call "xmalloc(256 * 1024)" in tst-decorate-maps is to force malloc() to
fall back to using mmap() since such an amount won't be available from the main heap.
Post 321e1fc73f, on Aarch64, the heap gets extended by default by at least 2MB, thus
the aforementioned call may get satisfied on the main heap itself. Thus, increase the amount
of memory requested to force the mmap() path again.