| Message ID | 20220606214414.736109-4-shy828301@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Cleanup transhuge_xxx helpers | expand |
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.
On Thu, Jun 9, 2022 at 4:24 PM Zach O'Keefe <zokeefe@google.com> wrote: > > 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. Nice catch! Totally possible. I did overlook this. I will drop this patch in the next version or maybe making the comment clearer is a better choice.
On 2022/6/7 5:44, Yang Shi 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; Is it possible that hugepage_vma_check returns true due to the shmem check, or file thp check since we dropped mmap_lock ? So anon vma is explicitly checked again here? Thanks! > return 0; > } > >
On 2022/6/10 15:23, Miaohe Lin wrote: > On 2022/6/7 5:44, Yang Shi 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; > > Is it possible that hugepage_vma_check returns true due to the shmem check, or file thp check since > we dropped mmap_lock ? So anon vma is explicitly checked again here? I just see your discussion with similar problem. Sorry for make noise. > > Thanks! > >> return 0; >> } >> >> >
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; }
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(-)