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

Nicholas Piggin npiggin at gmail.com
Sat Nov 11 20:09:51 AEDT 2017


On Fri, 10 Nov 2017 22:59:57 +0530
"Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com> wrote:

> Michael Ellerman <mpe at ellerman.id.au> writes:
> 
> > "Aneesh Kumar K.V" <aneesh.kumar at 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 at 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?

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.

Thanks,
Nick


More information about the Linuxppc-dev mailing list