From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR Date: Fri, 17 Feb 2017 13:04:46 -0800 Message-ID: References: <20170217141328.164563-1-kirill.shutemov@linux.intel.com> <20170217141328.164563-34-kirill.shutemov@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Linus Torvalds , "Kirill A. Shutemov" Cc: Andrew Morton , the arch/x86 maintainers , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Andy Lutomirski , "linux-arch@vger.kernel.org" , linux-mm , Linux Kernel Mailing List , Catalin Marinas , Linux API List-Id: linux-arch.vger.kernel.org On 02/17/2017 12:02 PM, Linus Torvalds wrote: > So if you use MAP_FIXED and give an address in the high range, it will > just always work, and the MM will always consider the task size to be > the full address space. > > But for the common case where a process does no use MAP_FIXED, the > kernel will never give a high address by default, and you have to do > the process control thing to say "I want those high addresses". > > Hmm? Assuming that folks tend to hard-code MAP_FIXED addresses, they'll be <48 bits and everything will work splendidly. But, if folks do something like take the CPU-enumerated virtual address size and use that as a starting point, I can see things breaking. MPX would definitely break if the hardware saw one of those high addresses and was not ready for it. It ends up just chopping off the high bits of the address, so: 0x10000000000000 and 0x20000000000000 index into the same spot in the bounds tables. It does this unless you put the hardware in the new mode that uses the larger tables, and consumes more bits of the virtual address. Is this likely to break anything in practice? Nah. But it would nice to avoid it. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:61109 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932757AbdBQVHv (ORCPT ); Fri, 17 Feb 2017 16:07:51 -0500 Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR References: <20170217141328.164563-1-kirill.shutemov@linux.intel.com> <20170217141328.164563-34-kirill.shutemov@linux.intel.com> From: Dave Hansen Message-ID: Date: Fri, 17 Feb 2017 13:04:46 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds , "Kirill A. Shutemov" Cc: Andrew Morton , the arch/x86 maintainers , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Andy Lutomirski , "linux-arch@vger.kernel.org" , linux-mm , Linux Kernel Mailing List , Catalin Marinas , Linux API Message-ID: <20170217210446.nl3fceTYmcX0tRYh802i_1AMj9iwbfeAxA8hlqWqIhY@z> On 02/17/2017 12:02 PM, Linus Torvalds wrote: > So if you use MAP_FIXED and give an address in the high range, it will > just always work, and the MM will always consider the task size to be > the full address space. > > But for the common case where a process does no use MAP_FIXED, the > kernel will never give a high address by default, and you have to do > the process control thing to say "I want those high addresses". > > Hmm? Assuming that folks tend to hard-code MAP_FIXED addresses, they'll be <48 bits and everything will work splendidly. But, if folks do something like take the CPU-enumerated virtual address size and use that as a starting point, I can see things breaking. MPX would definitely break if the hardware saw one of those high addresses and was not ready for it. It ends up just chopping off the high bits of the address, so: 0x10000000000000 and 0x20000000000000 index into the same spot in the bounds tables. It does this unless you put the hardware in the new mode that uses the larger tables, and consumes more bits of the virtual address. Is this likely to break anything in practice? Nah. But it would nice to avoid it.