linux-kernel - Re: [v3 PATCH 3/7] mm: khugepaged: remove the redundant anon vma check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAa6QmRTt2EXJTudBf7DK6yPTr2DRDUbGZiHDC8pAmKRwoB4_A@mail.gmail.com>
Date:   Thu, 9 Jun 2022 16:23:31 -0700
From:   "Zach O'Keefe" <zokeefe@...gle.com>
To:     Yang Shi <shy828301@...il.com>
Cc:     vbabka@...e.cz, kirill.shutemov@...ux.intel.com,
        willy@...radead.org, akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
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@...il.com> wrote:
>
> The hugepage_vma_check() already checked it, so remove the redundant
> check.
>
> Signed-off-by: Yang Shi <shy828301@...il.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.