On Tue, Feb 21, 2017 at 10:34:02AM +0000, Catalin Marinas wrote: > On Fri, Feb 17, 2017 at 03:21:27PM -0800, Linus Torvalds wrote: > > On Feb 17, 2017 3:02 PM, "Andy Lutomirski" <luto@xxxxxxxxxxxxxx> wrote: > > > What I'm trying to say is: if we're going to do the route of 48-bit > > > limit unless a specific mmap call requests otherwise, can we at least > > > have an interface that doesn't suck? > > > > No, I'm not suggesting specific mmap calls at all. I'm suggesting the complete > > opposite: not having some magical "max address" at all in the VM layer. Keep > > all the existing TASK_SIZE defines as-is, and just make those be the new 56-bit > > limit. > > > > But to then not make most processes use it, just make the default x86 > > arch_get_free_area() return an address limited to the old 47-bit limit. So > > effectively all legacy programs work exactly the same way they always did. > > arch_get_unmapped_area() changes would not cover STACK_TOP which is > currently defined as TASK_SIZE (on both x86 and arm64). I don't think it > matters much (normally such upper bits tricks are done on heap objects) > but you may find some weird user program that passes pointers to the > stack around and expects bits 48-63 to be masked out. If that's a real > issue, we could also limit STACK_TOP to 47-bit (48-bit on arm64). I've limited STACK_TOP to 47-bit in my implementation of Linus' proposal: http://lkml.kernel.org/r/20170220131515.GA9502@xxxxxxxxxxxxxxxxxx -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
