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

Nicholas Piggin [off-list ref] writes:

On Fri, 10 Nov 2017 22:59:57 +0530
"Aneesh Kumar K.V" [off-list ref] wrote:

quoted

Michael Ellerman [off-list ref] writes:

quoted

"Aneesh Kumar K.V" [off-list ref] writes:
 

quoted

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 <redacted>
---
 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