Re: [PATCH] powerpc/64s/slice: Use addr limit when computing slice mask

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

Nicholas Piggin <npiggin@gmail.com> writes:

> On Fri, 10 Nov 2017 22:59:57 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> Michael Ellerman <mpe@ellerman.id.au> writes:
>> 
>> > "Aneesh Kumar K.V" <aneesh.kumar@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.kumar@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