On Sun, Sep 18, 2022 at 5:48 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, 18 Sep 2022 14:47:47 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > > > Link: https://lore.kernel.org/r/0F7CF2A7-F671-4196-B8FD-F35E9556391B@xxxxxxxxx/ > > Suggested-by: Nadav Amit <nadav.amit@xxxxxxxxx> > > Signed-off-by: Yu Zhao <yuzhao@xxxxxxxxxx> > > --- > > mm/vmscan.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 5c4d9d0867ec..629518813b59 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -3904,7 +3904,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, > > continue; > > > > if (!ptep_test_and_clear_young(args->vma, addr, pte + i)) > > - continue; > > + VM_WARN_ON_ONCE(true); > > > > young++; > > walk->mm_stats[MM_LEAF_YOUNG]++; > > @@ -4637,7 +4637,7 @@ void lru_gen_look_around(struct page_vma_mapped_walk *pvmw) > > continue; > > > > if (!ptep_test_and_clear_young(pvmw->vma, addr, pte + i)) > > - continue; > > + VM_WARN_ON_ONCE(true); > > > > This is a functional change? More than the Subject: describes. No, since ptep_test_and_clear_young() shouldn't fail here. We are under the PTL and ascertained (a few lines above) pte_young() is true. Neither the h/w nor another thread can clear the accessed bit under us.
