On March 22, 2018 6:17:20 PM CDT, akpm@xxxxxxxxxxxxxxxxxxxx wrote: >From: Toshi Kani <toshi.kani@xxxxxxx> >Subject: mm/vmalloc: add interfaces to free unmapped page table > >On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may >create >pud/pmd mappings. Kernel panic was observed on arm64 systems with >Cortex-A75 in the following steps as described by Hanjun Guo. > > 1. ioremap a 4K size, valid page table will build, > 2. iounmap it, pte0 will set to 0; > 3. ioremap the same address with 2M size, pgd/pmd is unchanged, > then set the a new value for pmd; > 4. pte0 is leaked; > 5. CPU may meet exception because the old pmd is still in TLB, > which will lead to kernel panic. > >This panic is not reproducible on x86. INVLPG, called from iounmap, >purges all levels of entries associated with purged address on x86. >x86 >still has memory leak. > >The patch changes the ioremap path to free unmapped page table(s) since >doing so in the unmap path has the following issues: > > - The iounmap() path is shared with vunmap(). Since vmap() only > supports pte mappings, making vunmap() to free a pte page is an > overhead for regular vmap users as they do not need a pte page > freed up. > - Checking if all entries in a pte page are cleared in the unmap path > is racy, and serializing this check is expensive. > - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges. > Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB > purge. > >Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which >clear a given pud/pmd entry and free up a page for the lower level >entries. > >This patch implements their stub functions on x86 and arm64, which work >as >workaround. > >[akpm@xxxxxxxxxxxxxxxxxxxx: fix typo in pmd_free_pte_page() stub] >Link: >http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@xxxxxxx >Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings") >Reported-by: Lei Li <lious.lilei@xxxxxxxxxxxxx> >Signed-off-by: Toshi Kani <toshi.kani@xxxxxxx> >Cc: Catalin Marinas <catalin.marinas@xxxxxxx> >Cc: Wang Xuefeng <wxf.wang@xxxxxxxxxxxxx> >Cc: Will Deacon <will.deacon@xxxxxxx> >Cc: Hanjun Guo <guohanjun@xxxxxxxxxx> >Cc: Michal Hocko <mhocko@xxxxxxxx> >Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> >Cc: Ingo Molnar <mingo@xxxxxxxxxx> >Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> >Cc: Borislav Petkov <bp@xxxxxxx> >Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> >Cc: Chintan Pandya <cpandya@xxxxxxxxxxxxxx> >Cc: <stable@xxxxxxxxxxxxxxx> >Signed-off-by: Andrew Morton <> Some script ate your mail address. -- Sent from a small device: formatting sux and brevity is inevitable.