[PATCH v4 3/4] powerpc/mm: add radix__remove_section_mapping()

[Reza Arbab]

On Wed, Jan 04, 2017 at 10:37:58AM +0530, Aneesh Kumar K.V wrote:
>Reza Arbab <arbab at linux.vnet.ibm.com> writes:
>> +static void remove_pagetable(unsigned long start, unsigned long end)
>> +{
>> +	unsigned long addr, next;
>> +	pud_t *pud_base;
>> +	pgd_t *pgd;
>> +
>> +	spin_lock(&init_mm.page_table_lock);
>> +
>> +	for (addr = start; addr < end; addr = next) {
>> +		next = pgd_addr_end(addr, end);
>> +
>> +		pgd = pgd_offset_k(addr);
>> +		if (!pgd_present(*pgd))
>> +			continue;
>> +
>> +		if (pgd_huge(*pgd)) {
>> +			pte_clear(&init_mm, addr, (pte_t *)pgd);
>> +			continue;
>> +		}
>> +
>> +		pud_base = (pud_t *)pgd_page_vaddr(*pgd);
>> +		remove_pud_table(pud_base, addr, next);
>> +		free_pud_table(pud_base, pgd);
>> +	}
>> +
>> +	spin_unlock(&init_mm.page_table_lock);
>
>What is this lock protecting ?

The more I look into it, I'm not sure. This is still an artifact from 
the x86 functions, where they lock/unlock agressively, as you and Ben 
noted. I can take it out. 

>> +	flush_tlb_kernel_range(start, end);
>
>We can use radix__flush_tlb_kernel_range avoiding an if
>(radix_enabled()) conditional ?

Yes, good idea.

>(radix_enabled()) conditional ? Also if needed we could make all the
>above take a radix__ prefix ?

You mean rename all these new functions? We could, but I don't really 
see why. These functions are static to pgtable-radix.c, there aren't 
hash__ versions to differentiate from, and it seemed helpful to mirror 
the x86 names.

-- 
Reza Arbab