From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D588EC4829B for ; Mon, 12 Feb 2024 07:07:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 057366B006E; Mon, 12 Feb 2024 02:07:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F23806B0071; Mon, 12 Feb 2024 02:07:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE9256B0072; Mon, 12 Feb 2024 02:07:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CC2986B006E for ; Mon, 12 Feb 2024 02:07:47 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 51CD71A0943 for ; Mon, 12 Feb 2024 07:07:47 +0000 (UTC) X-FDA: 81782271774.14.AFB97DB Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf22.hostedemail.com (Postfix) with ESMTP id EFF88C0012 for ; Mon, 12 Feb 2024 07:07:43 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=m5dsn5i8; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=ak@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707721664; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=scUyUdBlS5wOYXvOCXz6jvFPejy4wS+4OX0W+JbSV8U=; b=vPrrrXjgIa0VC0puqjuPdBWKo0elUIIxi570gVWVBbAWW87vgVzr89U8SL4BxmCbWBGqRS 0BRl2rTvEWUOU3lfeYzau8r3eezH9Z69aGOtM/E03WG3iIzM690rVCHA+ziUS7hX7Qry0E tkxPMXHevYA1suZcw5gJxxS5kXX9LlA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=m5dsn5i8; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=ak@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707721664; a=rsa-sha256; cv=none; b=qv0M+fMyFipWlh3A0WCiWH8d0FZRGXSQ/0LHYkx1OBWeoQ9lmRVpU3okcyNhv3+Kxtu3xf FQSXerELVfQo5jyKZLbwGI0AIl13gin5LZxZ9Mzos6GOXnQU4hdxTU/T5rUAfZExl0yu2v j9oujvQ5ryyRqarJnl6J8Zv3o9PF6OE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707721664; x=1739257664; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=RCdOiggCm0l00XC8KnOXtFiS/o7OVO9sEQ1asC4jtCM=; b=m5dsn5i8GScjUMjgwLKctmbxjMRjb/Dd3jd8z010EDf/nhk0u9xoYMrw jCkE6s4G94CgE5khrkHMWZOcILqxpdk4JTIU24zrp4NhTjwy1paVSN/UC zs0PbIDxB7OhJmyVMqe3j7F4mAlaABp1P9C/dLLmd6Avii7056dkMg8pw ISiOa8wQIf+h7DESY5qiQPirr8A2I0B6NYe9a7flOSHfpUgPw3VTM95N6 LZwiYX6sX2VqSCoLgPwIzG8C4vH/nXBOU5RmvErcpiu0LORBSWdQIXDJe 7yGIXvavLjeLkQkywRmaEPeKtnspR+CEk5tsfko+FSDsi5Ec7S/25vrOz w==; X-IronPort-AV: E=McAfee;i="6600,9927,10981"; a="12412232" X-IronPort-AV: E=Sophos;i="6.05,262,1701158400"; d="scan'208";a="12412232" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2024 23:07:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,262,1701158400"; d="scan'208";a="2518876" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2024 23:07:41 -0800 Date: Sun, 11 Feb 2024 23:07:40 -0800 From: Andi Kleen To: Bagas Sanjaya Cc: hapter@420blaze.it, mingo@redhat.com, tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, Andrew Morton , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for MAP_32BIT's start address? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: EFF88C0012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gesh16bmosarrsai1fp8xjhsbj58dopt X-HE-Tag: 1707721663-954871 X-HE-Meta: U2FsdGVkX1+ZBVbsc+jHcGfUP5/DpQ0vaAtgaEg5P3u6wXf6UQzzw/59/+vgAUqGMrdnqnPv9QV/KR5WDs9onuQjbH2OtqFPSZ6kJqaaJR3JTWTudyoNr0eiUw8TgnjKrAQ7BwR9o9gGEz6+zSrqEf+hY2cKCllqKWMCaIgs3m9vzdNcQ31cXUCVvmFahE1I0q2MJTLSRZwGKqsKBEyaEJfwz9QfgP/JA0vyvwOTflHibtcJBBaPtHnkKTGVkc7M8zmfxANNJrZLKLOcZp4RNJlNXsNUelr5pcXXQ7RtJdx/eOQYnindL5ZX3g63cAC+WvAScDn91kfRvbcYwGTGuLF2BcBi0uEGZbfof09jtACHnd1ZLhysk8GqjiYJMuCPdzIyHQC0nwX5uLJdlkqjq8UQ639wThMKTh+p8rwxx1ODhSGy6eo/kWxwpDrk6K/e3qLy/3WrFSM6JBw69zKNrxQy9W9OQXnv2ERSrOz62PulKGR/HCYSb44wkCp6hOhw/YA9vr/Y0MsR7AZk6YxmKkPqPnwj93TrxTERrZC4I//tRRrTdrqXGTIl/juCnMP+38j1HcKb9r58Puy6zzH3jGSEfluEdq70X5IxYCfEoRNeGOrkZWVPxyZESnVPlH7eZYAnOAwHJb32fOkbh8mtDkYevvtAAHfQPwqEvzg5bcwXpYx6g2/PwEJrY1bd1Dtv2LtfV7SMU8CCPLd3GZ09lxMXNQR9Ucc/BnYEbXXg092q+t1/Nd0ju4jdirbEbwuNoaecWUrMgA6LKCl9I3ZzxsxByEDMH9SypcRuTJ4jhDyBDdwW0wzqcTOt7ZaWB4LTNdV7xQluEHf6P2azAgrR/3Ee0n1BqwW0W4HXNXjAt/cyfqxWGyXD4bBX08Zckf8Htkn2TWXwrIWHbyv+J58qnkDycID95x+lYFhNV/+SIn7za6gkQ9R8ysM940BkHe0jgBH4MeUywzaJrgt3ciT SSs8tzOB AatCiwakeDceQMj5mWlzow+RsT35BCDDbCaZhQZX8uIEsTen1M4ETLJaQyrkVuVNm/hBvshaTya0oZrNv8/vPdqQO76c32RadXjZrQ0/cyw4RJWSAvLSZ+kxIf1uZqDbDMHmQn3PZw9vgTDeQmaJDWkXMkujhq0JeH65eG1ekuS8HNNKjYJSV76x7aRXWWzHbG1/PRfUNUXTAva1sJKxRMCNAH3QO58Mw4Ciujq8YshRh61MdPZ2JFxqz38Ae5/JxxMyUJbFSYJ41T7SuGU8ZtOEv7Qq0HboqeoZZT4I5f+PmhXyiDxUxEhFpHcFn6azq/OFdSiBKV9ed1xWPg/9QvchnuVEAHBvGO53WXZZo6jCFsBg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > >> 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 I thought the comment was clear? The 1GB start is to avoid conflicts with the brk heap, which grows up. The flag is really obsolete, if you want limited relocations there are better ways to do it that don't limit ASLR. It was originally because the custom module loader in X.org didn't support a PLT. -Andi