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

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

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