From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754757AbdDGKKY (ORCPT ); Fri, 7 Apr 2017 06:10:24 -0400 Received: from mail-db5eur01on0134.outbound.protection.outlook.com ([104.47.2.134]:51956 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752982AbdDGKKN (ORCPT ); Fri, 7 Apr 2017 06:10:13 -0400 Authentication-Results: virtuozzo.com; dkim=none (message not signed) header.d=none;virtuozzo.com; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits To: "Kirill A. Shutemov" References: <20170406140106.78087-1-kirill.shutemov@linux.intel.com> <20170406140106.78087-9-kirill.shutemov@linux.intel.com> <3cb79f4b-76f5-6e31-6973-e9281b2e4553@virtuozzo.com> <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> CC: Linus Torvalds , Andrew Morton , , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , , , From: Dmitry Safonov Message-ID: <27affbe2-0150-526e-d47b-d5c1292e9187@virtuozzo.com> Date: Fri, 7 Apr 2017 13:06:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6PR0802CA0034.eurprd08.prod.outlook.com (10.172.252.148) To DB6PR0801MB1735.eurprd08.prod.outlook.com (10.169.226.150) X-MS-Office365-Filtering-Correlation-Id: eab4c63f-e772-4574-21f4-08d47d9e45a0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:DB6PR0801MB1735; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1735;3:HU6ETKEn4QTMh89Pr0OSp97RX/yEOI0GU2PJfyI0kOaZVrphsABcRUpI4LLGDtyFmtG/bt63mO+GS+AbsXwqY3PP+9vKDoMzowP/0C4l9UsSWEeOv/IY3zfJ7kSBsWtUz/ZfxIm6QkxVz4amjQ9YDuBnB+dvv8ZqI8NJre+BXB2pAvw7xSLRzm6l6+iUP6H/P0CUQoWm2U4mUGeMOpxlohA6nWiLbEmK78bJcTlqlNpCUPxb2Wqi8vXECw9edPTfl68/QCGBdmNd7YS0NWs6SlWF0oi5O9/3bqyaW/vuXsRt5GcSXcce69Eu5/RsKWsC9Qjq2Ll5omuA4DDAEFReYw==;25:rioyQV6mPi3jyeZwqGI+cYHxBjSFOphhqVDKnQ266a6f3dDF0IB0J1RtpnibrOjyuyurB+rrzXkn9TW4mGdcnSnakYx1kdF/Vr5fY5gXlb2zZHsiwv/HnRjrf+Ifk9t3x74Z2iOJZK9jwX/5p+TXKL6i+GVld2Ht+KKyGaL5F7pPur8+V6Hop94Ij2t045eud9IZXznp7ut4mbGfwi/yEt1UJ4wRLjGpSb+jrl73hAqDz6JosswJCtGMn1QcvdTop3QGPSEkFqcgkv5u30fhJSb0+jTvGiQkUsEx/GSB9Y4kCq0V094eiSCHxtKs4V+nyCSZQr+4B4V3ZFkFY891H/Mk/vYVCDuskZpdwhdGS/CBYZ1QILmfzaBWZuPYuVWF1LRxwGSxeVo1DJblEYPfzmgzwvYUfw4E+dKm6CUOkC36UOdi2KDWFEuDDmslzZgerc9pC9EYqEBbvylwTHMFCg== X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1735;31:LeOeLekuE2JuM2awH36f9fJ26DLfF0woyAln4Ci/KSpUcjS1n8+OmDotrNw9JcL5hTwFGZ6Fw2Ifh8O/ajc927r9W77mmbc/7JU7wEB6ExZ1EJYX3mmTiPke+7MYHyMN6jnClTJkURclRHHHhEbImTkx596szNMKtC2L8rCn3v9W6UcG4BF+OUSQD9zX+/kqgplBTohjxDG2ZzZcXpvsMQLtHuQsMQAi4PgaIilsKZs=;20:BoQOUIzxGB2jlgherKrmVkcqW1H2oLnOSdvy0ECi7P5fpFlS2WQgF7hnEw5h1FEAeDBiQqVF3Bah6q/i2zkGQd5Ol4rfwl3c9IzKRbvcbSd06uwrK4vzBqtBL7HqQ7ERAxg4nSuznASAzJ9qU/WyoGthrNSm1e60NG/R0ykh+eLKiL/bk6teztwHSHqYjgfouYIcNW0r2uhgSNUBuonKf0DINrbWokHvL8oqxifdP5h6AMCa+RieZg2aUZTFWxJR/c4b2jeDjrX/TAe7FLh80B2RZ74wVaM/HsSPwZ13mCZQwxp6DXJCIF18qxLjMkAdzIziOv4B+DdPtEsByjO8lqj+AqZTeT8pK3xNdc/Zlxrstni2YS+HGCNExgCiLxxKU3CsR3+r2VXggvjEa6hSiB0ZlF9VwjJiu7Iw55pqNVo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148);SRVR:DB6PR0801MB1735;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB1735; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1735;4:zJRusmF3W2lmaQ+6tQM7fG+Nx1kLEu4iNo2VTqOTnd0Cm0cmaoEm9iZqWqfmRZBHKgVt6gRVs4ld6CGpSuip7LEAF5eYiPmp3WtWncH3xaYfax84kq6SYHgweXf/zjuvu+o0m1enNEfoM3Ix7nNFcjeHQycq2paE2VCJdvML7q3mFUzifcCCdOZgw3b3emb7rRr3+zozZ0gu2ZTFR8SXxdPb83IBH6v9X72fuxqL7Pf9Mba7miRjXFVRy9SfkWQggWmCuWCvNMNMeujKcbCsD1Fmz7AZRNLkh1c+fZoQ7IMuau9EPn4hboJmx0KD7bfm+iIDP81MmMjcRQGwDu6RDF85k+w3gCRRZD9z6YOstq6yrsP2xs5gJS0NuX9erFL9L2I5+DvJ2YSdg82lR9TTCkGu8AMe9zYzliFIj6/lmRQ4oCnhQtwuDz1aJnUGHzak47P+Gq2J580aK2Z7epF8SbrRjFgcfU7DzwlmHsT65F1CtgmLXB7czvcxkVmcZYswDVD236B10FutDNkmLLY1E/YGsW2yUzwJfkK1rkdBX41bUC5VCTJ12zr6er1pMy2BcHqWHmiIG56HxAJhls1303Ci0ZFOQV70t8QbPYeBcNud03Elij+/KVDm9T9cvz0FmQWloK9KBGHbpl91atHQxdZVuEAHgElyGBOJ7YeWbs3puDM1rKEZBbR7ZfTwtFfMK08izOvs4j3ldS3Y7wRMmw== X-Forefront-PRVS: 0270ED2845 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39450400003)(39410400002)(377454003)(24454002)(54356999)(42186005)(5660300001)(64126003)(65826007)(76176999)(31686004)(31696002)(305945005)(65806001)(86362001)(50986999)(2906002)(8676002)(6116002)(25786009)(81166006)(47776003)(7416002)(230700001)(50466002)(53546009)(66066001)(3846002)(4326008)(23746002)(33646002)(54906002)(2950100002)(6666003)(189998001)(110136004)(38730400002)(6486002)(77096006)(6246003)(93886004)(53936002)(36756003)(90366009)(6916009)(573474001);DIR:OUT;SFP:1102;SCL:1;SRVR:DB6PR0801MB1735;H:[172.16.25.13];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB6PR0801MB1735;23:LcMfQUw/wK1a8PgqRLuHYUeITB1UPYMXORt?= =?Windows-1252?Q?rMdiYPg212+NuaRoE3eRGCuImr465jFHVRTyDqC+1bbdTEnxN8444o2M?= =?Windows-1252?Q?kdm+efYpDPIxm7GRVcb24GmA0os2AFFJYarf0LzJx5B1rd1fVpBjJsuo?= =?Windows-1252?Q?scV2yhEcxZB4IcwYj/O4gxZkHFfKoiV8DNUJdAfqVMtQgPHs0Tl5Jer9?= =?Windows-1252?Q?JxdE1y77BwfjV5txr6KgofeuX9PSr6x+oFmh0gKPTKuo9KNVVPgUh3tV?= =?Windows-1252?Q?Z+YStOan5iiUwIAuPtXHLmJbkAnCBGjTTMDxyJX9+WqIr8eN3zJ6sDD3?= =?Windows-1252?Q?wA53LJ8D3ryoD4gmh3Mp7NU+vOr5aaYGS0rTYWBI/aohUWYCglDdD8VC?= =?Windows-1252?Q?mSxFrvvhs6cNnVNcJl0NFY3V3b1/roxK3pKy4dWId9omIWm0u9VZXQF1?= =?Windows-1252?Q?0DFFkMMh6ZyONqlui1GLoxe+u9vPpWuLsfw9sNG5+Qu5jyDcKBwoGC4Z?= =?Windows-1252?Q?a93w8tWDiLfEsqcrr7CIpHpCmxyRZgX0fJE3QT6Z3dei0R/f9sNjeHM0?= =?Windows-1252?Q?Td/nPpqGa3Kcr4GKaNQYrDJAqLuye99jCCD5an6gpqNywd+JJapOHzw6?= =?Windows-1252?Q?BsQiRhtKhviX7/NjXnHmivSSEt+oOeM89/OdtTVP6j5COB8wgGsBQLoX?= =?Windows-1252?Q?XqvYXeoeHQiZiFuHxJrIkedlpW8a7sRFoa9x9sTkc0dmWVbIcxnhsVT3?= =?Windows-1252?Q?se65zhLOpBPNRnaEwS3nYNHNmy48bXDILAYb/wNPYTdrwGWg42uRHc0h?= =?Windows-1252?Q?39fPwAXhWxex2xYa41iaLGqsdvZNO3MAzpIkjjCeBVHJQ0Zri8pc8N83?= =?Windows-1252?Q?T/GngstDwcR4qAoWpseeAWW/0xmH1FO5IiGoc3Qlbab13/6sUXhqoZKz?= =?Windows-1252?Q?klIOQH7hWfxxGnP0Pe9uWaLjrkoLmiao6bHgl3R6LSjbQWcrIdNtUAoq?= =?Windows-1252?Q?i8hWd2OQs75+NXpRIhDiSAt/liGk8jLFM8Pp+mrwY2BhLOnTx0uZS4+Z?= =?Windows-1252?Q?PaiJNMoT4ch/0iQjMW8G6Z7PZ9GdTxWzrZWqNfcm42atWNsYhwcK6WP5?= =?Windows-1252?Q?jIjzT9soAalz+BamHFv0mCJgeL6drZYyHtJhLpoont9R12jb0jXMTvI9?= =?Windows-1252?Q?9CaOKaeeWyaYVAfoKqGks19mA/Zte7zXh4ppZbe1R4XUto9jZQK3gs1l?= =?Windows-1252?Q?glHIjYD6d8L4Zeio1/TtRiGok8ZuAYBFYqmpbqQStF2Tq+zhu2qOQJQe?= =?Windows-1252?Q?lpva2Wri4Xf1cS5d56lqSVEw+gA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1735;6:TJ0iJtnPS+6MSk1FcyiEUvLNrLSiiE2qXZGK4O1Mwu8EFtGPTvE3JLfd2xAUAp/hJ15xkk1ZFquWosrQo5wytHdfNGJ/hemnUoJDV88l1Gt48S1Fw+OqRqCP1MBITpPL2qpUw5dJiTAQXKz0jQEU3R34+710vAEAEUgsHGH962nnO0370Bnuz3TlJVEPz2kV8ucSzJpea9e3jMFMjD+7IanKtcbL35xiufGXXliDdT9PNtQBPUOjADuSe5XyVfcvFK5IJMeh983yAV1cwb8Pj6uqIDmlO3BCll4ysARgWOTGULQ8X8FvbaDOiDyaqspHkZtCyVcgr09RuMF5/1NvUWRWyF3goS+kMDypTivqqW0ml9OXNCqf0oLohwmvkH1jGSlEVJ+8Vef1CTORJvYjqQ==;5:MKMY4mTXQ6J7L5MwLUwdxxLgpGZJwBvRpUGWRe8QoHT8A1yMMBIP2rUsTYSO9sAjlB10momaaK3LoJFOSlMhg/npc/HV3Y12f8QnjVF4JjVl9tnKVfuiwRCyF9Z2caWfR2igvO7CTt9OlbECGUDWng==;24:e5p60/PCXKPnE5XDU756pWQ1SqYJ2KNzCcKyBTgWp6YHk0M2+ZndV2QrvTCKsf9gI292siRqmZMoqC+rI8NRdiad7IWl8bWtwbOqvT/oDa4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1735;7:PFLX/ZOXUEt/fd2+LdOkR00hdFea5Q4gKNShPmGwmPGuRo4/iFVlKs4oK/h+BtsNgceV6vNOIFClrolyyeuDheoP80D4U2bXkKJJCBr9ZlWVwpyJqQ0iVuRoZXkzGGA1nUDkt1i9NoVw8E8TgoyFvtibJAziWOjzb/97wUQk+NTtRE8mfsb5ElNotkkgit0X4ByGgXQFbVceAYTXTcHOWINi7vsurrN0Nfp8zF9isvuOMnFifIcLAnvaWlVZzdWr/SXoaHUrRZDMaEF1ywsY4FOUy+dsXuFKCQk5lzGVHlOTccNtBIaTmvtDyidcYTIanSSFixnPMGfmSUKciGqtnw==;20:DYrIWeC4wJDK8YZsIitD2ynEJJAGywTBEefNp3F0eLhenErtiAJDiw7WyA++T/Xz9Ac5bYt/+WCU/ztO2dKqzzAcklgZoDYvWB58kf4f1upM+7JcFTK2NykmBOO8tAgElGimNzIbtX/euW1pPXcNLZ4tVRS7/cxjHWAOUKfwXcs= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2017 10:10:08.2641 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1735 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/07/2017 02:21 AM, Kirill A. Shutemov wrote: > On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: >> On 04/06/2017 09:43 PM, Dmitry Safonov wrote: >>> Hi Kirill, >>> >>> On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: >>>> On x86, 5-level paging enables 56-bit userspace virtual address space. >>>> Not all user space is ready to handle wide addresses. It's known that >>>> at least some JIT compilers use higher bits in pointers to encode their >>>> information. It collides with valid pointers with 5-level paging and >>>> leads to crashes. >>>> >>>> To mitigate this, we are not going to allocate virtual address space >>>> above 47-bit by default. >>>> >>>> But userspace can ask for allocation from full address space by >>>> specifying hint address (with or without MAP_FIXED) above 47-bits. >>>> >>>> If hint address set above 47-bit, but MAP_FIXED is not specified, we try >>>> to look for unmapped area by specified address. If it's already >>>> occupied, we look for unmapped area in *full* address space, rather than >>>> from 47-bit window. >>> >>> Do you wish after the first over-47-bit mapping the following mmap() >>> calls return also over-47-bits if there is free space? >>> It so, you could simplify all this code by changing only mm->mmap_base >>> on the first over-47-bit mmap() call. >>> This will do simple trick. > > No. > > I want every allocation to explicitely opt-in large address space. It's > additional fail-safe: if a library can't handle large addresses it has > better chance to survive if its own allocation will stay within 47-bits. Ok > >> I just tried to define it like this: >> -#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE) >> +#define DEFAULT_MAP_WINDOW (test_thread_flag(TIF_ADDR32) ? \ >> + IA32_PAGE_OFFSET : ((1UL << 47) - >> PAGE_SIZE)) >> >> And it looks working better. > > Okay, thanks. I'll send v2. > >>>> + if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall()) >>>> + info.high_limit += TASK_SIZE - DEFAULT_MAP_WINDOW; >>> >>> Hmm, TASK_SIZE depends now on TIF_ADDR32, which is set during exec(). >>> That means for ia32/x32 ELF which has TASK_SIZE < 4Gb as TIF_ADDR32 >>> is set, which can do 64-bit syscalls - the subtraction will be >>> a negative.. > > With your proposed change to DEFAULT_MAP_WINDOW difinition it should be > okay, right? I'll comment to v2 to keep all in one place. -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Safonov Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits Date: Fri, 7 Apr 2017 13:06:35 +0300 Message-ID: <27affbe2-0150-526e-d47b-d5c1292e9187@virtuozzo.com> References: <20170406140106.78087-1-kirill.shutemov@linux.intel.com> <20170406140106.78087-9-kirill.shutemov@linux.intel.com> <3cb79f4b-76f5-6e31-6973-e9281b2e4553@virtuozzo.com> <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-db5eur01on0134.outbound.protection.outlook.com ([104.47.2.134]:51956 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752982AbdDGKKN (ORCPT ); Fri, 7 Apr 2017 06:10:13 -0400 In-Reply-To: <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Kirill A. Shutemov" Cc: Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org On 04/07/2017 02:21 AM, Kirill A. Shutemov wrote: > On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: >> On 04/06/2017 09:43 PM, Dmitry Safonov wrote: >>> Hi Kirill, >>> >>> On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: >>>> On x86, 5-level paging enables 56-bit userspace virtual address space. >>>> Not all user space is ready to handle wide addresses. It's known that >>>> at least some JIT compilers use higher bits in pointers to encode their >>>> information. It collides with valid pointers with 5-level paging and >>>> leads to crashes. >>>> >>>> To mitigate this, we are not going to allocate virtual address space >>>> above 47-bit by default. >>>> >>>> But userspace can ask for allocation from full address space by >>>> specifying hint address (with or without MAP_FIXED) above 47-bits. >>>> >>>> If hint address set above 47-bit, but MAP_FIXED is not specified, we try >>>> to look for unmapped area by specified address. If it's already >>>> occupied, we look for unmapped area in *full* address space, rather than >>>> from 47-bit window. >>> >>> Do you wish after the first over-47-bit mapping the following mmap() >>> calls return also over-47-bits if there is free space? >>> It so, you could simplify all this code by changing only mm->mmap_base >>> on the first over-47-bit mmap() call. >>> This will do simple trick. > > No. > > I want every allocation to explicitely opt-in large address space. It's > additional fail-safe: if a library can't handle large addresses it has > better chance to survive if its own allocation will stay within 47-bits. Ok > >> I just tried to define it like this: >> -#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE) >> +#define DEFAULT_MAP_WINDOW (test_thread_flag(TIF_ADDR32) ? \ >> + IA32_PAGE_OFFSET : ((1UL << 47) - >> PAGE_SIZE)) >> >> And it looks working better. > > Okay, thanks. I'll send v2. > >>>> + if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall()) >>>> + info.high_limit += TASK_SIZE - DEFAULT_MAP_WINDOW; >>> >>> Hmm, TASK_SIZE depends now on TIF_ADDR32, which is set during exec(). >>> That means for ia32/x32 ELF which has TASK_SIZE < 4Gb as TIF_ADDR32 >>> is set, which can do 64-bit syscalls - the subtraction will be >>> a negative.. > > With your proposed change to DEFAULT_MAP_WINDOW difinition it should be > okay, right? I'll comment to v2 to keep all in one place. -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id 5219B6B03A4 for ; Fri, 7 Apr 2017 06:10:14 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id p64so49083550oif.0 for ; Fri, 07 Apr 2017 03:10:14 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0090.outbound.protection.outlook.com. [104.47.2.90]) by mx.google.com with ESMTPS id a15si2207024otd.125.2017.04.07.03.10.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 03:10:13 -0700 (PDT) Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits References: <20170406140106.78087-1-kirill.shutemov@linux.intel.com> <20170406140106.78087-9-kirill.shutemov@linux.intel.com> <3cb79f4b-76f5-6e31-6973-e9281b2e4553@virtuozzo.com> <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> From: Dmitry Safonov Message-ID: <27affbe2-0150-526e-d47b-d5c1292e9187@virtuozzo.com> Date: Fri, 7 Apr 2017 13:06:35 +0300 MIME-Version: 1.0 In-Reply-To: <20170406232137.uk7y2knbkcsru4pi@black.fi.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Kirill A. Shutemov" Cc: Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org On 04/07/2017 02:21 AM, Kirill A. Shutemov wrote: > On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: >> On 04/06/2017 09:43 PM, Dmitry Safonov wrote: >>> Hi Kirill, >>> >>> On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: >>>> On x86, 5-level paging enables 56-bit userspace virtual address space. >>>> Not all user space is ready to handle wide addresses. It's known that >>>> at least some JIT compilers use higher bits in pointers to encode their >>>> information. It collides with valid pointers with 5-level paging and >>>> leads to crashes. >>>> >>>> To mitigate this, we are not going to allocate virtual address space >>>> above 47-bit by default. >>>> >>>> But userspace can ask for allocation from full address space by >>>> specifying hint address (with or without MAP_FIXED) above 47-bits. >>>> >>>> If hint address set above 47-bit, but MAP_FIXED is not specified, we try >>>> to look for unmapped area by specified address. If it's already >>>> occupied, we look for unmapped area in *full* address space, rather than >>>> from 47-bit window. >>> >>> Do you wish after the first over-47-bit mapping the following mmap() >>> calls return also over-47-bits if there is free space? >>> It so, you could simplify all this code by changing only mm->mmap_base >>> on the first over-47-bit mmap() call. >>> This will do simple trick. > > No. > > I want every allocation to explicitely opt-in large address space. It's > additional fail-safe: if a library can't handle large addresses it has > better chance to survive if its own allocation will stay within 47-bits. Ok > >> I just tried to define it like this: >> -#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE) >> +#define DEFAULT_MAP_WINDOW (test_thread_flag(TIF_ADDR32) ? \ >> + IA32_PAGE_OFFSET : ((1UL << 47) - >> PAGE_SIZE)) >> >> And it looks working better. > > Okay, thanks. I'll send v2. > >>>> + if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall()) >>>> + info.high_limit += TASK_SIZE - DEFAULT_MAP_WINDOW; >>> >>> Hmm, TASK_SIZE depends now on TIF_ADDR32, which is set during exec(). >>> That means for ia32/x32 ELF which has TASK_SIZE < 4Gb as TIF_ADDR32 >>> is set, which can do 64-bit syscalls - the subtraction will be >>> a negative.. > > With your proposed change to DEFAULT_MAP_WINDOW difinition it should be > okay, right? I'll comment to v2 to keep all in one place. -- Dmitry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org