All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: hapter@420blaze.it, mingo@redhat.com
Cc: tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com, Andi Kleen <ak@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for MAP_32BIT's start address?
Date: Mon, 12 Feb 2024 09:48:30 +0700	[thread overview]
Message-ID: <dc60d456-3f02-4076-8adf-4688cfa03aeb@gmail.com> (raw)
In-Reply-To: <ZcmF3SrTACMULEPb@archie.me>

On 2/12/24 09:43, Bagas Sanjaya wrote:
> On Sun, Feb 11, 2024 at 08:52:45AM +0000, hapter@420blaze.it 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



  reply	other threads:[~2024-02-12  2:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-11  8:52 arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for MAP_32BIT's start address? hapter
2024-02-12  2:43 ` Bagas Sanjaya
2024-02-12  2:48   ` Bagas Sanjaya [this message]
2024-02-12  7:07     ` Andi Kleen
2024-02-12  2:53 ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc60d456-3f02-4076-8adf-4688cfa03aeb@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hapter@420blaze.it \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.