Nicholas Piggin <npig...@gmail.com> writes:
> On Fri, 10 Nov 2017 22:59:57 +0530
> "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> wrote:
>
>> Michael Ellerman <m...@ellerman.id.au> writes:
>>
>> > "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> writes:
>> >
>> >> While computing slice mask for the free area we need make sure we only
>> >> search
>> >> in the addr limit applicable for this mmap. We update the slb_addr_limit
>> >> after we request for a mmap above 128TB. But the following mmap request
>> >> with hint addr below 128TB should still limit its search to below 128TB.
>> >> ie.
>> >> we should not use slb_addr_limit to compute slice mask in this case.
>> >> Instead,
>> >> we should derive high addr limit based on the mmap hint addr value.
>> >>
>> >> Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com>
>> >> ---
>> >> arch/powerpc/mm/slice.c | 34 ++++++++++++++++++++++------------
>> >> 1 file changed, 22 insertions(+), 12 deletions(-)
>> >
>> > How does this relate to the fixes Nick has sent?
>>
>> This patch is on top of the patch series sent by Nick. Without this
>> patch we will allocate memory across the 128TB range if hint_addr <
>> 128TB but hint_addr + len is more. Inorder to recreate this issue we
>> will have to map stack below. Hence one won't hit the error in general
>> case.
>
> I couldn't get it to trigger this case after that series -- hash
> get_unmapped_area should be excluding that case up front before
> getting into the slice allocator. Do you have an strace to reproduce
> it?
That is correct. This change in slice_get_unmapped_area prevents the
issue I mentioned above. I did have that hunk reverted to check the error
mask creation.
- if (addr > mm->task_size - len ||
+ if (addr > high_limit - len ||
!slice_area_is_free(mm, addr, len))
addr = 0;
}
>
> Either way I do think it would be good to tighten up all the slice
> bitmap limits, including all the other places that hardcodes the
> max bitmap size.
>
-aneesh
