hi，Toshi
The old flow of reuse the 4k page as 2M page does not follow the BBM flow for page table reconstruction，not only the memory leak problems. If BBM flow is not followed，the speculative prefetch of tlb will made false tlb entries cached in MMU, the false address will be got， panic will happen.
THANKS
wang xuefeng
Sent from HUAWEI AnyOffice
The old flow of reuse the 4k page as 2M page does not follow the BBM flow for page table reconstruction，not only the memory leak problems. If BBM flow is not followed，the speculative prefetch of tlb will made false tlb entries cached in MMU, the false address will be got， panic will happen.
THANKS
wang xuefeng
Sent from HUAWEI AnyOffice
发件人：Kani, Toshi
收件人：linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,cpandya@xxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx,郭寒军
抄送：Linuxarm,linux-mm@xxxxxxxxx,王雪峰,akpm@xxxxxxxxxxxxxxxxxxxx,mark.rutland@xxxxxxx,will.deacon@xxxxxxx,catalin.marinas@xxxxxxx,Hocko, Michal,hanjun.guo@xxxxxxxxxx
时间：2018-02-21 08:34:49
主题:Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
On Tue, 2018-02-20 at 14:54 +0530, Chintan Pandya wrote:
>
> On 12/28/2017 4:54 PM, Hanjun Guo wrote:
> > From: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
> >
> > When we using iounmap() to free the 4K mapping, it just clear the PTEs
> > but leave P4D/PUD/PMD unchanged, also will not free the memory of page
> > tables.
> >
> > This will cause issues on ARM64 platform (not sure if other archs have
> > the same issue) for this case:
> >
> > 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.
> >
> > Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is
> > zero.
> >
>
> One obvious problem I see here is, once any 2nd level entry has 3rd
> level mapping, this entry can't map 2M section ever in future. This way,
> we will fragment entire virtual space over time.
>
> The code you are changing is common between 32-bit systems as well (I
> think). And running out of section mapping would be a reality in
> practical terms.
>
> So, if we can do the following as a fix up, we would be saved.
> 1) Invalidate 2nd level entry from TLB, and
> 2) Free the page which holds last level page table
>
> BTW, is there any further discussion going on this topic which I am
> missing ?
Yes, I suggested to free up a pte table in my last reply.
https://patchwork.kernel.org/patch/10134581/
Thanks,
-Toshi
>
> On 12/28/2017 4:54 PM, Hanjun Guo wrote:
> > From: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
> >
> > When we using iounmap() to free the 4K mapping, it just clear the PTEs
> > but leave P4D/PUD/PMD unchanged, also will not free the memory of page
> > tables.
> >
> > This will cause issues on ARM64 platform (not sure if other archs have
> > the same issue) for this case:
> >
> > 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.
> >
> > Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is
> > zero.
> >
>
> One obvious problem I see here is, once any 2nd level entry has 3rd
> level mapping, this entry can't map 2M section ever in future. This way,
> we will fragment entire virtual space over time.
>
> The code you are changing is common between 32-bit systems as well (I
> think). And running out of section mapping would be a reality in
> practical terms.
>
> So, if we can do the following as a fix up, we would be saved.
> 1) Invalidate 2nd level entry from TLB, and
> 2) Free the page which holds last level page table
>
> BTW, is there any further discussion going on this topic which I am
> missing ?
Yes, I suggested to free up a pte table in my last reply.
https://patchwork.kernel.org/patch/10134581/
Thanks,
-Toshi
