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

[Adhemerval Zanella Netto]

On 22/12/25 01:45, Dev Jain wrote:
> 
> 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.
> 

Works for me, thanks.