Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220606214414.736109-1-shy828301@gmail.com> <20220606214414.736109-4-shy828301@gmail.com>
 <CAAa6QmRTt2EXJTudBf7DK6yPTr2DRDUbGZiHDC8pAmKRwoB4_A@mail.gmail.com>
In-Reply-To: <CAAa6QmRTt2EXJTudBf7DK6yPTr2DRDUbGZiHDC8pAmKRwoB4_A@mail.gmail.com>
From:   Yang Shi <shy828301@gmail.com>
Date:   Thu, 9 Jun 2022 17:01:40 -0700
Message-ID: <CAHbLzkqhH5oJmQ6YMvBoAW17t03nqwJsrxfzw4gXtP_mTtnWAg@mail.gmail.com>
Subject: Re: [v3 PATCH 3/7] mm: khugepaged: remove the redundant anon vma check
To:     "Zach O'Keefe" <zokeefe@google.com>
Cc:     Vlastimil Babka <vbabka@suse.cz>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.