On Mar 19, 2017 09:25, "Aneesh Kumar K.V" [off-list ref]
wrote:

"Kirill A. Shutemov" [off-list ref] writes:

On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:

quoted

"Kirill A. Shutemov" [off-list ref] writes:

quoted

On x86, 5-level paging enables 56-bit userspace virtual address space.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use higher bits in pointers to encode their
information. It collides with valid pointers with 5-level paging and
leads to crashes.

To mitigate this, we are not going to allocate virtual address space
above 47-bit by default.

But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.

If hint address set above 47-bit, but MAP_FIXED is not specified, we

try

quoted

quoted

to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather

than

quoted

quoted

from 47-bit window.

This approach helps to easily make application's memory allocator aware
about large address space without manually tracking allocated virtual
address space.

So if I have done a successful mmap which returned > 128TB what should a
following mmap(0,...) return ? Should that now search the *full* address
space or below 128TB ?

No, I don't think so. And this implementation doesn't do this.

It's safer this way: if an library can't handle high addresses, it's
better not to switch it automagically to full address space if other part
of the process requested high address.

What is the epectation when the hint addr is below 128TB but addr + len >
128TB ? Should such mmap request fail ?


Yes, I believe so.