# Re: \[PATCH v4 3/4\] powerpc/mm: add radix\_\_remove\_section\_mapping()

- From: Reza Arbab \<hidden\>
- Date: 2017-01-04 21:28:25 
- List: linuxppc-dev
- Page: https://ratatoskr.run/linuxppc-dev/2017/01/9494522
- Thread: https://ratatoskr.run/linuxppc-dev/2017/01/9494473/t.md

```text
On Wed, Jan 04, 2017 at 10:37:58AM +0530, Aneesh Kumar K.V wrote:
>Reza Arbab [ref] 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
```