From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luck, Tony" Subject: RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Date: Wed, 28 Mar 2018 21:07:30 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B3B8BC5@ORSMSX110.amr.corp.intel.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> <20180327234904.GA27734@bombadil.infradead.org> <20180328000025.GM1436@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Kate Stewart , Linux MIPS Mailing List , Jan Kara , linux-sh , Ilya Smith , Bhupesh Sharma , Heiko Carstens , Michal Hocko , Linux-MM , Paul Mackerras , Deepa Dinamani , "H. Peter Anvin" , sparclinux , "linux-ia64@vger.kernel.org" , "Williams, Dan J" , Andrea Arcangeli , linux-s390 , Yoshinori Sato , Helge Deller , X86 ML , Hugh Dickins , Russell King , "nitin.m.gupta@oracle.com" , Matthew Wilcox Return-path: In-Reply-To: <20180328000025.GM1436@brightrain.aerifal.cx> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org > The default limit of only 65536 VMAs will also quickly come into play > if consecutive anon mmaps don't get merged. Of course this can be > raised, but it has significant resource and performance (fork) costs. Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one. That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created. -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AIpwx48Fg51z1gfysh4Fj3i47M6zqdUHMRNyxDME+XZ35hHnOG/z4Kh3w8ntWLAt8q8VKCM7UnQL ARC-Seal: i=1; a=rsa-sha256; t=1522271252; cv=none; d=google.com; s=arc-20160816; b=Xfh/bGUAT+2kwugTShc5lxLcptoiHQiAzdYw2aYSkYZOMe4+3P9uoC6QFWEG1BvJZe 7bH8HYuS/jNEpFZrvUhVtV4c0eaa4dCq03YbiajV19j2GgIkA1o70Xn9llE+80Lt0W26 nih1Sp+o1t3jQCfgF/9O0uESNh1m4+X5qg7VOPXn4zuqXWBFilM4G0UgIfkRjHVURj8m gpN9lGfGanZtYqJzZbkHgOK80+IcdOb5XAt7kqEYXm+JNQwzMn7Ewer18+v4ckWJZVGI GaKWAkgOLzB5QkTBk+ry/cmTAB25sxx69uNjmF7j2AS2PKsO4eYvLoP8T33oq6WoyaCI i9hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:dlp-reaction:dlp-version :dlp-product:content-language:accept-language:in-reply-to:references :message-id:date:thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=dexk/TWoqvx5X0x+Q82JbeJivpFxXrRniCs3RygtDrg=; b=Ivc67NkXnd8f3/TD5YmM3+1p25k66A9OQe0tQChKvIR/efZO39SPiqE2dsuCSCf3Sa YaTd0tNfDuuGeC6C7ugyx31fdCdr1M2Z3X7QB+mvGxxPzRzInXUQ4CzBPe+82VvITK5A bJ3kfJoWJ0I2EXh4vHKxPWkDT1TGOVz9XoiYP0MMD3W1IkzrONUr7VljcOwG5NVE9l9V QfAnS78xtYJVG0zzeynPxrRu4ZZ/uhi0EF+tsjuya8l+jkOTY7V2aYeDaski5GBUguYt 5UWXimMFmH7kJR7+vbPkx1QvC9FZQj+H4+oPNzabzymn4LxG23axUZuW+1wV3fU5Ty1p lqLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of tony.luck@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=tony.luck@intel.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of tony.luck@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=tony.luck@intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,373,1517904000"; d="scan'208";a="212130243" From: "Luck, Tony" To: Rich Felker , Matthew Wilcox CC: Kees Cook , Ilya Smith , Michal Hocko , Richard Henderson , "ink@jurassic.park.msu.ru" , "mattst88@gmail.com" , Vineet Gupta , Russell King , "Yu, Fenghua" , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , "Michael Ellerman" , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , "David S. Miller" , "Thomas Gleixner" , Ingo Molnar , "H. Peter Anvin" , X86 ML , "nyc@holomorphy.com" , Al Viro , Arnd Bergmann , Greg KH , Deepa Dinamani , Hugh Dickins , Kate Stewart , Philippe Ombredanne , Andrew Morton , Steve Capper , Punit Agrawal , "Aneesh Kumar K.V" , Nick Piggin , Bhupesh Sharma , Rik van Riel , "nitin.m.gupta@oracle.com" , "Kirill A. Shutemov" , "Williams, Dan J" , Jan Kara , Ross Zwisler , Jerome Glisse , "Andrea Arcangeli" , Oleg Nesterov , "linux-alpha@vger.kernel.org" , LKML , "linux-snps-arc@lists.infradead.org" , "linux-ia64@vger.kernel.org" , "linux-metag@vger.kernel.org" , Linux MIPS Mailing List , linux-parisc , PowerPC , linux-s390 , linux-sh , sparclinux , Linux-MM Subject: RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Thread-Topic: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Thread-Index: AQHTwfv/6OYZeJeUs0u250ucIkhOV6PeO8EAgABV+oCABB2cAIAAuAiAgADDTgCAAGwEAIAAl6SAgAAPawCAAAMsgIAA6zcw Date: Wed, 28 Mar 2018 21:07:30 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B3B8BC5@ORSMSX110.amr.corp.intel.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> <20180327234904.GA27734@bombadil.infradead.org> <20180328000025.GM1436@brightrain.aerifal.cx> In-Reply-To: <20180328000025.GM1436@brightrain.aerifal.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjkzNTdjYTQtNTkzMi00YjMwLTlmZDYtYTU2NThkMWMyMjM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJlaHB6QnBNXC8xMlk2YWYyRGtPZVp6YjNkMm1ocGd0VEZ3dG5RWFZxWGxGTDlBYmNuSU5jZUdZTTVBZzZFUERCUCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1595656488556903336?= X-GMAIL-MSGID: =?utf-8?q?1596217101035568514?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > The default limit of only 65536 VMAs will also quickly come into play > if consecutive anon mmaps don't get merged. Of course this can be > raised, but it has significant resource and performance (fork) costs. Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one. That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created. -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Mar 2018 23:07:42 +0200 (CEST) Received: from mga11.intel.com ([192.55.52.93]:64295 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23994621AbeC1VHeXzydC convert rfc822-to-8bit (ORCPT ); Wed, 28 Mar 2018 23:07:34 +0200 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2018 14:07:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,373,1517904000"; d="scan'208";a="212130243" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga005.jf.intel.com with ESMTP; 28 Mar 2018 14:07:31 -0700 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 28 Mar 2018 14:07:31 -0700 Received: from orsmsx110.amr.corp.intel.com ([169.254.10.11]) by ORSMSX153.amr.corp.intel.com ([169.254.12.120]) with mapi id 14.03.0319.002; Wed, 28 Mar 2018 14:07:30 -0700 From: "Luck, Tony" To: Rich Felker , Matthew Wilcox CC: Kees Cook , Ilya Smith , Michal Hocko , Richard Henderson , "ink@jurassic.park.msu.ru" , "mattst88@gmail.com" , Vineet Gupta , Russell King , "Yu, Fenghua" , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , "Michael Ellerman" , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , "David S. Miller" , "Thomas Gleixner" , Ingo Molnar , "H. Peter Anvin" , X86 ML , "nyc@holomorphy.com" , Al Viro , Arnd Bergmann , Greg KH , Deepa Dinamani , Hugh Dickins , Kate Stewart , Philippe Ombredanne , Andrew Morton , Steve Capper , Punit Agrawal , "Aneesh Kumar K.V" , Nick Piggin , Bhupesh Sharma , Rik van Riel , "nitin.m.gupta@oracle.com" , "Kirill A. Shutemov" , "Williams, Dan J" , Jan Kara , Ross Zwisler , Jerome Glisse , "Andrea Arcangeli" , Oleg Nesterov , "linux-alpha@vger.kernel.org" , LKML , "linux-snps-arc@lists.infradead.org" , "linux-ia64@vger.kernel.org" , "linux-metag@vger.kernel.org" , Linux MIPS Mailing List , linux-parisc , PowerPC , linux-s390 , linux-sh , sparclinux , Linux-MM Subject: RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Thread-Topic: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Thread-Index: AQHTwfv/6OYZeJeUs0u250ucIkhOV6PeO8EAgABV+oCABB2cAIAAuAiAgADDTgCAAGwEAIAAl6SAgAAPawCAAAMsgIAA6zcw Date: Wed, 28 Mar 2018 21:07:30 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B3B8BC5@ORSMSX110.amr.corp.intel.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> <20180327234904.GA27734@bombadil.infradead.org> <20180328000025.GM1436@brightrain.aerifal.cx> In-Reply-To: <20180328000025.GM1436@brightrain.aerifal.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjkzNTdjYTQtNTkzMi00YjMwLTlmZDYtYTU2NThkMWMyMjM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJlaHB6QnBNXC8xMlk2YWYyRGtPZVp6YjNkMm1ocGd0VEZ3dG5RWFZxWGxGTDlBYmNuSU5jZUdZTTVBZzZFUERCUCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 63319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tony.luck@intel.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips > The default limit of only 65536 VMAs will also quickly come into play > if consecutive anon mmaps don't get merged. Of course this can be > raised, but it has significant resource and performance (fork) costs. Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one. That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created. -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony.luck@intel.com (Luck, Tony) Date: Wed, 28 Mar 2018 21:07:30 +0000 Subject: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. In-Reply-To: <20180328000025.GM1436@brightrain.aerifal.cx> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> <20180327234904.GA27734@bombadil.infradead.org> <20180328000025.GM1436@brightrain.aerifal.cx> List-ID: Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B3B8BC5@ORSMSX110.amr.corp.intel.com> To: linux-snps-arc@lists.infradead.org > The default limit of only 65536 VMAs will also quickly come into play > if consecutive anon mmaps don't get merged. Of course this can be > raised, but it has significant resource and performance (fork) costs. Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one. That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created. -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luck, Tony" Subject: RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Date: Wed, 28 Mar 2018 21:07:30 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F7B3B8BC5@ORSMSX110.amr.corp.intel.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> <20180327234904.GA27734@bombadil.infradead.org> <20180328000025.GM1436@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20180328000025.GM1436@brightrain.aerifal.cx> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Rich Felker , Matthew Wilcox Cc: Kate Stewart , Linux MIPS Mailing List , Jan Kara , linux-sh , Ilya Smith , Bhupesh Sharma , Heiko Carstens , Michal Hocko , Linux-MM , Paul Mackerras , Deepa Dinamani , "H. Peter Anvin" , sparclinux , "linux-ia64@vger.kernel.org" , "Williams, Dan J" , Andrea Arcangeli , linux-s390 , Yoshinori Sato , Helge Deller , X86 ML , Hugh Dickins , Russell King , "nitin.m.gupta@oracle.com" > The default limit of only 65536 VMAs will also quickly come into play > if consecutive anon mmaps don't get merged. Of course this can be > raised, but it has significant resource and performance (fork) costs. Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one. That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created. -Tony