Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for MAP_32BIT's start address?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/12/24 09:43, Bagas Sanjaya wrote:
> On Sun, Feb 11, 2024 at 08:52:45AM +0000, hapter@xxxxxxxxxxx wrote:
>> I've found that passing in MAP_32BIT for mmap() will always return an
>> address above 0x40000000. The problem seems to lie in
> From one gigabyte up?
>> arch/x86/kernek/sys_x86_64.c, where the following comment is the only thing
>> close to a hint(Line 100):
>>
>> /* This is usually used needed to map code in small
>>    model, so it needs to be in the first 31bit. Limit
>>    it to that.  This means we need to move the
>>    unmapped base down for this case. This can give
>>    conflicts with the heap, but we assume that glibc
>>    malloc knows how to fall back to mmap. Give it 1GB
>>    of playground for now. -AK */
>>
>> Unfortunately this does not supply a rationale for starting from 0x40000000,
>> which seems very arbitrary, and the git commit has been there since the
>> beginning of time (i.e. as far the the git history goes), so the git blame
>> has not helped much to clarify it. I was also not able to find who "AK" was.
> 
> That was from commit 717db2f9f36805 ("[PATCH] x86-64 updates for 2.5.54")
> in tglx/history.git repo [1], authored by Andi Kleen. Cc'ing him.
> 

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/x86_64/kernel/sys_x86_64.c?id=717db2f9f36805d85c695771ea7d712812896aa7

-- 
An old man doll... just what I always wanted! - Clara





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux