Messages in this thread | | | Date | Sat, 2 Jul 2022 18:12:33 +0800 | Subject | Re: [PATCH v3] arm64: mm: fix linear mapping mem access performance degradation | From | "guanghui.fgh" <> |
| |
Thanks.
在 2022/7/2 1:24, Catalin Marinas 写道: > On Thu, Jun 30, 2022 at 06:50:22PM +0800, Guanghui Feng wrote: >> +static void init_pmd_remap(pud_t *pudp, unsigned long addr, unsigned long end, >> + phys_addr_t phys, pgprot_t prot, >> + phys_addr_t (*pgtable_alloc)(int), int flags) >> +{ >> + unsigned long next; >> + pmd_t *pmdp; >> + phys_addr_t map_offset; >> + pmdval_t pmdval; >> + >> + pmdp = pmd_offset(pudp, addr); >> + do { >> + next = pmd_addr_end(addr, end); >> + >> + if (!pmd_none(*pmdp) && pmd_sect(*pmdp)) { >> + phys_addr_t pte_phys = pgtable_alloc(PAGE_SHIFT); >> + pmd_clear(pmdp); >> + pmdval = PMD_TYPE_TABLE | PMD_TABLE_UXN; >> + if (flags & NO_EXEC_MAPPINGS) >> + pmdval |= PMD_TABLE_PXN; >> + __pmd_populate(pmdp, pte_phys, pmdval); >> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > This doesn't follow the architecture requirements for "break before > make" when changing live page tables. While it may work, it risks > triggering a TLB conflict abort. The correct sequence normally is: > > pmd_clear(); > flush_tlb_kernel_range(); > __pmd_populate(); > > However, do we have any guarantees that the kernel doesn't access the > pmd range being unmapped temporarily? The page table itself might live > in one of these sections, so set_pmd() etc. can get a translation fault. > Thanks. I'll follow this. I'll resend the path as soon as possible.
| |