On Thu, 26 May 2022 09:37:43 -0400 Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> wrote:
> On Thu, May 26, 2022 at 9:34 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, May 26, 2022 at 07:33:50PM +0800, Miaohe Lin wrote:
> > > ptep is unmapped too early, so ptep will be accessed while it's unmapped.
> > > Fix it by deferring pte_unmap() until page table checking is done.
> > >
> > > Fixes: 80110bbfbba6 ("mm/page_table_check: check entries at pmd levels")
> > > Signed-off-by: Miaohe Lin <linmiaohe@xxxxxxxxxx>
> > > ---
> > > mm/page_table_check.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/mm/page_table_check.c b/mm/page_table_check.c
> > > index 3692bea2ea2c..971c3129b0e3 100644
> > > --- a/mm/page_table_check.c
> > > +++ b/mm/page_table_check.c
> > > @@ -234,11 +234,11 @@ void __page_table_check_pte_clear_range(struct mm_struct *mm,
> > > pte_t *ptep = pte_offset_map(&pmd, addr);
> > > unsigned long i;
> > >
> > > - pte_unmap(ptep);
> > > for (i = 0; i < PTRS_PER_PTE; i++) {
> > > __page_table_check_pte_clear(mm, addr, *ptep);
> > > addr += PAGE_SIZE;
> > > ptep++;
> > > }
> > > + pte_unmap(ptep);
> >
> > But ptep was mutated in the loop. So surely this needs to be:
> >
> > pte_unmap(ptep - PTRS_PER_PTE);
> >
> > or you'll be unmapping the wrong page.
>
> Right, thank you Matthew.
>
> Miaohe, please store the ptep, or maybe drop this patch entirely.
I think it's best to fix it. I rewrote the changelog as
: ptep is unmapped too early, so ptep could theoretically be accessed while
: it's unmapped. This might become a problem if/when CONFIG_HIGHPTE becomes
: available on riscv.
:
: Fix it by deferring pte_unmap() until page table checking is done.
I'll retain the Fixes:. This doesn't imply cc:stable in MM, and anyone
who backports the original patchset will want to know about this fixup.
And I queued a fixup for the thing Matthew noticed.
