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). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
