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