From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) by kanga.kvack.org (Postfix) with ESMTP id 73F986B0253 for ; Wed, 11 Jan 2017 13:09:39 -0500 (EST) Received: by mail-vk0-f72.google.com with SMTP id j12so203529559vkd.2 for ; Wed, 11 Jan 2017 10:09:39 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com. [2607:f8b0:400c:c08::22d]) by mx.google.com with ESMTPS id a138si1753615vke.102.2017.01.11.10.09.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 10:09:38 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 96so92111333uaq.3 for ; Wed, 11 Jan 2017 10:09:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20170111142904.GD4895@node.shutemov.name> References: <20161227015413.187403-1-kirill.shutemov@linux.intel.com> <20161227015413.187403-30-kirill.shutemov@linux.intel.com> <5a3dcc25-b264-37c7-c090-09981b23940d@intel.com> <20170105192910.q26ozg4ci4i3j2ai@black.fi.intel.com> <161ece66-fbf4-cb89-3da6-91b4851af69f@intel.com> <978d5f1a-ec4d-f747-93fd-27ecfe10cb88@intel.com> <20170111142904.GD4895@node.shutemov.name> From: Andy Lutomirski Date: Wed, 11 Jan 2017 10:09:17 -0800 Message-ID: Subject: Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: "Kirill A. Shutemov" Cc: Dave Hansen , "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , X86 ML , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , linux-arch , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Linux API On Wed, Jan 11, 2017 at 6:29 AM, Kirill A. Shutemov wrote: > On Thu, Jan 05, 2017 at 12:49:44PM -0800, Dave Hansen wrote: >> On 01/05/2017 12:14 PM, Andy Lutomirski wrote: >> >> I'm not sure I'm comfortable with this. Do other rlimit changes cause >> >> silent data corruption? I'm pretty sure doing this to MPX would. >> >> >> > What actually goes wrong in this case? That is, what combination of >> > MPX setup of subsequent allocations will cause a problem, and is the >> > problem worse than just a segfault? IMO it would be really nice to >> > keep the messy case confined to MPX. >> >> The MPX bounds tables are indexed by virtual address. They need to grow >> if the virtual address space grows. There's an MSR that controls >> whether we use the 48-bit or 57-bit layout. It basically decides >> whether we need a 2GB (48-bit) or 1TB (57-bit) bounds directory. >> >> The question is what we do with legacy MPX applications. We obviously >> can't let them just allocate a 2GB table and then go let the hardware >> pretend it's 1TB in size. We also can't hand the hardware using a 2GB >> table an address >48-bits. >> >> Ideally, I'd like to make sure that legacy MPX can't be enabled if this >> RLIMIT is set over 48-bits (really 47). I'd also like to make sure that >> legacy MPX is active, that the RLIMIT can't be raised because all hell >> will break loose when the new addresses show up. > > I think we can do this. See the patch below. > > Basically, we refuse to enable MPX and issue warning in dmesg if there's > anything mapped above 47-bits. Once MPX is enabled, mmap_max_addr() cannot > be higher than 47-bits too. > > Function call from mmap_max_addr() is unfortunate, but I don't see a > way around. How about preventing the max addr from being changed to too high a value while MPX is on instead of overriding the set value? This would have the added benefit that it would prevent silent failures where you think you've enabled large addresses but MPX is also on and mmap refuses to return large addresses. -- 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