[PATCH] mm/khugepaged: check compound_order() in collapse_pte_mapped_thp()

[PATCH] mm/khugepaged: check compound_order() in collapse_pte_mapped_thp()

[Zach O'Keefe]

By the time we lock a page in collapse_pte_mapped_thp(), the page
mapped by the address pushed onto the slot's .pte_mapped_thp[] array
might have changed arbitrarily since we last looked at it.  We
revalidate that the page is still the head of a compound page, but we
don't revalidate if the compound page is of order HPAGE_PMD_ORDER before
applying rmap and page table updates.

Since the kernel now supports large folios of arbitrary order, and since
replacing page's pte mappings by a pmd mapping only makes sense for
compound pages of order HPAGE_PMD_ORDER, revalidate that the compound
order is indeed of order HPAGE_PMD_ORDER before proceeding.

Suggested-by: Yang Shi <shy828301@gmail.com>
Signed-off-by: Zach O'Keefe <zokeefe@google.com>
---

Andrew, could you please take this into mm-unstable as a prerequisite
patch for the "mm: add file/shmem support to MADV_COLLAPSE" series?
Thank you.

 mm/khugepaged.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 122cb72435e3..30f35d646f11 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1448,6 +1448,11 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr,
 		goto drop_hpage;
 	}
 
+	if (compound_order(hpage) != HPAGE_PMD_ORDER) {
+		result = SCAN_PAGE_COMPOUND;
+		goto drop_hpage;
+	}
+
 	result = find_pmd_or_thp_or_none(mm, haddr, &pmd);
 	switch (result) {
 	case SCAN_SUCCEED:
-- 
2.37.3.998.g577e59143f-goog

Re: [PATCH] mm/khugepaged: check compound_order() in collapse_pte_mapped_thp()

[Zach O'Keefe]

On Wed, Sep 21, 2022 at 3:10 PM Zach O'Keefe <zokeefe@google.com> wrote:
>
> By the time we lock a page in collapse_pte_mapped_thp(), the page
> mapped by the address pushed onto the slot's .pte_mapped_thp[] array
> might have changed arbitrarily since we last looked at it.  We
> revalidate that the page is still the head of a compound page, but we
> don't revalidate if the compound page is of order HPAGE_PMD_ORDER before
> applying rmap and page table updates.
>
> Since the kernel now supports large folios of arbitrary order, and since
> replacing page's pte mappings by a pmd mapping only makes sense for
> compound pages of order HPAGE_PMD_ORDER, revalidate that the compound
> order is indeed of order HPAGE_PMD_ORDER before proceeding.
>
> Suggested-by: Yang Shi <shy828301@gmail.com>
> Signed-off-by: Zach O'Keefe <zokeefe@google.com>
> ---
>
> Andrew, could you please take this into mm-unstable as a prerequisite
> patch for the "mm: add file/shmem support to MADV_COLLAPSE" series?
> Thank you.
>
>  mm/khugepaged.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 122cb72435e3..30f35d646f11 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1448,6 +1448,11 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr,
>                 goto drop_hpage;
>         }
>
> +       if (compound_order(hpage) != HPAGE_PMD_ORDER) {
> +               result = SCAN_PAGE_COMPOUND;
> +               goto drop_hpage;
> +       }
> +
>         result = find_pmd_or_thp_or_none(mm, haddr, &pmd);
>         switch (result) {
>         case SCAN_SUCCEED:
> --
> 2.37.3.998.g577e59143f-goog
>

Apologies, I forgot the relevant Link tag:

Link: https://lore.kernel.org/linux-mm/CAHbLzkon+2ky8v9ywGcsTUgXM_B35jt5NThYqQKXW2YV_GUacw@mail.gmail.com/

Re: [PATCH] mm/khugepaged: check compound_order() in collapse_pte_mapped_thp()

[Zach O'Keefe]

On Wed, Sep 21, 2022 at 3:39 PM Zach O'Keefe <zokeefe@google.com> wrote:
>
> On Wed, Sep 21, 2022 at 3:10 PM Zach O'Keefe <zokeefe@google.com> wrote:
> >
> > By the time we lock a page in collapse_pte_mapped_thp(), the page
> > mapped by the address pushed onto the slot's .pte_mapped_thp[] array
> > might have changed arbitrarily since we last looked at it.  We
> > revalidate that the page is still the head of a compound page, but we
> > don't revalidate if the compound page is of order HPAGE_PMD_ORDER before
> > applying rmap and page table updates.
> >
> > Since the kernel now supports large folios of arbitrary order, and since
> > replacing page's pte mappings by a pmd mapping only makes sense for
> > compound pages of order HPAGE_PMD_ORDER, revalidate that the compound
> > order is indeed of order HPAGE_PMD_ORDER before proceeding.
> >
> > Suggested-by: Yang Shi <shy828301@gmail.com>
> > Signed-off-by: Zach O'Keefe <zokeefe@google.com>
> > ---
> >
> > Andrew, could you please take this into mm-unstable as a prerequisite
> > patch for the "mm: add file/shmem support to MADV_COLLAPSE" series?
> > Thank you.
> >
> >  mm/khugepaged.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index 122cb72435e3..30f35d646f11 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -1448,6 +1448,11 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr,
> >                 goto drop_hpage;
> >         }
> >
> > +       if (compound_order(hpage) != HPAGE_PMD_ORDER) {
> > +               result = SCAN_PAGE_COMPOUND;
> > +               goto drop_hpage;
> > +       }
> > +
> >         result = find_pmd_or_thp_or_none(mm, haddr, &pmd);
> >         switch (result) {
> >         case SCAN_SUCCEED:
> > --
> > 2.37.3.998.g577e59143f-goog
> >
>
> Apologies, I forgot the relevant Link tag:
>
> Link: https://lore.kernel.org/linux-mm/CAHbLzkon+2ky8v9ywGcsTUgXM_B35jt5NThYqQKXW2YV_GUacw@mail.gmail.com/

Apologies x2 ; I mentioned this was a prerequisite for the "mm: add
file/shmem support to MADV_COLLAPSE" series, but it's based on the
current mm-unstable (which includes said series, and thus doesn't even
compile). I'll send a v2 of this patch emminitely, along with a v4 of
the "mm: add file/shmem support to MADV_COLLAPSE" series - applied in
the correct order.