Re: [PATCH] arch/powerpc/mm/slice: Cleanup leftover use of task_size

[Aneesh Kumar K.V]

On Thursday 13 April 2017 05:13 PM, Rick Lindsley wrote:
On 04/13/2017 03:58 AM, Aneesh Kumar K.V wrote:

I would suggest we don't do this change now. But rather we audit the
usage of TASK_SIZE(), mm->task_size and move them correctly to
mm->task_size and mm->context.addr_limit. The context.addr_limit is
added as an optimization for slice_mask copy and we need to closely
audit to make sure we can use that as a boundary condition for error
checking in case of mmap.

I do agree that extending the address space could affect other
code because of the use of TASK_SIZE. and we need to examine
"the big picture" to resolve the usage of addr_limit, task_size,
and TASK_SIZE. But without this small change now, I don't see how
the extended address space is made available at all in the non-radix
case. Are we acknowledging that 512TB address space is only available
when radix is enabled?


Those code path you modified doesn't control the address allocation. The 
relevant bits are

        /*
         * This mmap request can allocate upt to 512TB
         */
        if (addr > DEFAULT_MAP_WINDOW)
                high_limit = mm->context.addr_limit;
        else
                high_limit = DEFAULT_MAP_WINDOW;
        

and for topdown search

        addr = mm->mmap_base;
        /*
         * If we are trying to allocate above DEFAULT_MAP_WINDOW
         * Add the different to the mmap_base.
         * Only for that request for which high_limit is above
         * DEFAULT_MAP_WINDOW we should apply this.
         */
        if (high_limit  > DEFAULT_MAP_WINDOW)
                addr += mm->context.addr_limit - DEFAULT_MAP_WINDOW;


and for bottom up search

        addr = TASK_UNMAPPED_BASE;
        /*
         * Check till the allow max value for this mmap request
         */
        while (addr < high_limit) {
        

-aneesh