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:

quoted

On Feb 17, 2017 3:02 PM, "Andy Lutomirski" [off-list ref] wrote:

quoted

  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@node.shutemov.name

-- 
 Kirill A. Shutemov

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>