Messages in this thread | | | From | "Zach O'Keefe" <> | Date | Thu, 9 Jun 2022 16:23:31 -0700 | Subject | Re: [v3 PATCH 3/7] mm: khugepaged: remove the redundant anon vma check |
| |
On Mon, Jun 6, 2022 at 2:44 PM Yang Shi <shy828301@gmail.com> wrote: > > The hugepage_vma_check() already checked it, so remove the redundant > check. > > Signed-off-by: Yang Shi <shy828301@gmail.com> > --- > mm/khugepaged.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index d0f8020164fc..7a5d1c1a1833 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -966,9 +966,6 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address, > return SCAN_ADDRESS_RANGE; > if (!hugepage_vma_check(vma, vma->vm_flags)) > return SCAN_VMA_CHECK; > - /* Anon VMA expected */ > - if (!vma->anon_vma || !vma_is_anonymous(vma)) > - return SCAN_VMA_CHECK; > return 0; > } > > -- > 2.26.3 > >
So, I don't know if this is possible, but I wonder if there is a race here:
hugepage_vma_revalidate() is called in the anon path when mmap_lock after dropped + reacquired, and we want to refind / revalidate the vma, since it might have changed.
There is the possibility that the memory was unmapped, then remapped as file or shmem. If so, hugepage_vma_check() could return true without actually checking vma->anon_vma || !vma_is_anonymous(vma) - and we probably do want to (re)validate that this is indeed still an anon vma.
| |