[PATCH 0/5] VA allocator fixes

[Aneesh Kumar K.V]

On 11/07/2017 05:36 AM, Nicholas Piggin wrote:
> On Mon, 6 Nov 2017 16:16:07 +0100
> Florian Weimer <fweimer at redhat.com> wrote:
> 
>> On 11/06/2017 11:03 AM, Nicholas Piggin wrote:
>>> Florian found a nasty corner case with the VA allocation logic
>>> for crossing from 128TB to 512TB limit on hash, and made a
>>> really superb report of the problem -- traces, reproducer recipes,
>>> analysis, etc. which already mostly solved it.
>>>
>>> The first patch in the series should solve Florian's particular
>>> case, the next 3 are other issues with addr_limit. The last
>>> patch is technically a cleanup but I think it's fairly important
>>> in terms of understanding the code and also enabling some BUG
>>> checks (when addr_limit == 0).
>>>
>>> I have not tested these exactly on Florian's test case, but
>>> some tests of my own behave better afterwards. Hopefully he has
>>> time to re-test. Some careful review would be welcome too.
>>
>> I think I have applied the five patches you posted, but I still get a
>> brk value above 128 TiB:
>>
>> # /lib64/ld64.so.1 ./a.out
>> initial brk value: 0x7fffde960000
>> probing at 0x80000001fffc
>>
>> I assumed you wanted to reject those?
> 
> It was difficult to understand what the intended semantics are, but I
> think brk should succeed (it is implemented with MAP_FIXED). Of course
> it should not succeed then segfault when you try to access it.
> 
>>
>> In either case, I recommend to tweak the VM layout, so that ld.so does
>> not land closely to to the 128 TiB limit, so that the brk failure or
>> returning of 48-bit addresses is avoided.
> 
> Yeah well that's yet another issue. I was not really involved with the
> address space extension work. Anees, Kirill, was the intention for the
> 128T->512T extension logic to be a no-op for all address space allocaiton
> except those with explicit addresses?
> 

yes.

-aneesh