The hugepage_vma_check() already checked it, so remove the redundant
check.
Signed-off-by: Yang Shi <[email protected]>
---
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
On Mon, Jun 6, 2022 at 2:44 PM Yang Shi <[email protected]> wrote:
>
> The hugepage_vma_check() already checked it, so remove the redundant
> check.
>
> Signed-off-by: Yang Shi <[email protected]>
> ---
> 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 <[email protected]> wrote:
>
> On Mon, Jun 6, 2022 at 2:44 PM Yang Shi <[email protected]> wrote:
> >
> > The hugepage_vma_check() already checked it, so remove the redundant
> > check.
> >
> > Signed-off-by: Yang Shi <[email protected]>
> > ---
> > 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.