| Message ID | 20220921221043.547580-1-zokeefe@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/khugepaged: check compound_order() in collapse_pte_mapped_thp() | expand |
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/
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.
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:
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(+)