Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1603613 > unrolled thread

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-03-17 21:40 +0100
    Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above  47-bits "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-03-18 18:10 +0100
      Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-03-19 09:30 +0100
        Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-03-19 14:10 +0100
          Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above  47-bits "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-03-24 10:10 +0100
        Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits Michael Ellerman <mpe@ellerman.id.au> - 2017-03-20 10:20 +0100
        Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits hpa@zytor.com - 2017-03-20 19:10 +0100
          Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above  47-bits Matthew Wilcox <willy@infradead.org> - 2017-03-20 20:40 +0100
          Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above  47-bits "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-03-24 10:10 +0100

#1603613 — Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> 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
> to look for unmapped area by specified address. If it's already
> occupied, we look for unmapped area in *full* address space, rather than
> 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 ?

-aneesh

[toc] | [next] | [standalone]

#1603820 — Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:
> 
> > 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
> > to look for unmapped area by specified address. If it's already
> > occupied, we look for unmapped area in *full* address space, rather than
> > 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.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1603923

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
>> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:
>> 
>> > 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
>> > to look for unmapped area by specified address. If it's already
>> > occupied, we look for unmapped area in *full* address space, rather than
>> > 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 ?

-aneesh

[toc] | [prev] | [next] | [standalone]

#1603971

"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:

> "Kirill A. Shutemov" <kirill@shutemov.name> writes:
>
>> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
>>> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:
>>> 
>>> > 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
>>> > to look for unmapped area by specified address. If it's already
>>> > occupied, we look for unmapped area in *full* address space, rather than
>>> > 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 ?

Considering that we have stack at the top (around 128TB) we may not be
able to get a free area for such a request. But I guess the idea here is
that if hint address is below 128TB, we behave as though our TASK_SIZE
is 128TB ? Is that correct ?
 
-aneesh

[toc] | [prev] | [next] | [standalone]

#1608249 — Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On Sun, Mar 19, 2017 at 02:25:08PM +0530, Aneesh Kumar K.V wrote:
> >>> 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 ?
> 
> Considering that we have stack at the top (around 128TB) we may not be
> able to get a free area for such a request. But I guess the idea here is
> that if hint address is below 128TB, we behave as though our TASK_SIZE
> is 128TB ? Is that correct ?

Right.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1604264

"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> "Kirill A. Shutemov" <kirill@shutemov.name> writes:
>> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
>>> 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 ?

Yeah I think that makes sense, it retains the existing behaviour unless
the hint itself is >= 128TB.

cheers

[toc] | [prev] | [next] | [standalone]

#1604938

On March 19, 2017 1:26:58 AM PDT, "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
>On Mar 19, 2017 09:25, "Aneesh Kumar K.V"
><aneesh.kumar@linux.vnet.ibm.com>
>wrote:
>
>"Kirill A. Shutemov" <kirill@shutemov.name> writes:
>
>> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
>>> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:
>>>
>>> > 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
>>> > to look for unmapped area by specified address. If it's already
>>> > occupied, we look for unmapped area in *full* address space,
>rather
>than
>>> > 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.

This *better* be conditional on some kind of settable limit.  Having a barrier in the middle of the address space for no apparent reason to "clean" software is insane.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1605093 — Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On Mon, Mar 20, 2017 at 11:08:41AM -0700, hpa@zytor.com wrote:
> On March 19, 2017 1:26:58 AM PDT, "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
> >On Mar 19, 2017 09:25, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > > What is the epectation when the hint addr is below 128TB but addr + len
> > > 128TB ? Should such mmap request fail ?
> >
> >Yes, I believe so.
> 
> This *better* be conditional on some kind of settable limit.  Having a
> barrier in the middle of the address space for no apparent reason to
> "clean" software is insane.

I disagree with Kirill here.  If addr+len > 128TB, I think we should
assume the application is 57-bit aware.

Specifying hint addresses is such a rare thing to do anyway.

[toc] | [prev] | [next] | [standalone]

#1608247 — Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On Mon, Mar 20, 2017 at 11:08:41AM -0700, hpa@zytor.com wrote:
> This *better* be conditional on some kind of settable limit.  Having a
> barrier in the middle of the address space for no apparent reason to
> "clean" software is insane.

I had the same argument (on your side) before, but if you look on numbers
it's far from the middle of address space. The barrier is around 0.2% from
the start 56-bit address space.

And it's we have vdso/vvar/stack just below the barier anyway.

I don't think we would loose much if wouldn't not allow VMA to sit
across it.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web