Re: [PATCH v3 4/5] mm: hugetlb: fix missing cache flush in hugetlb_mcopy_atomic_pte()
From: Mike Kravetz
Date: Tue Feb 01 2022 - 17:24:26 EST
Cc: Matthew
On 1/31/22 08:02, Muchun Song wrote:
> folio_copy() will copy the data from one page to the target page, then
> the target page will be mapped to the user space address, which might
> have an alias issue with the kernel address used to copy the data from
> the page to. Fix this issue by flushing dcache but not use
> flush_dcache_folio() since it is not backportable.
>
> Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY")
> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> ---
> mm/hugetlb.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a1baa198519a..f1f1ab31dc8a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -5804,6 +5804,8 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
> goto out;
> }
> } else {
> + int i, nr;
> +
> if (vm_shared &&
> hugetlbfs_pagecache_present(h, dst_vma, dst_addr)) {
> put_page(*pagep);
> @@ -5819,6 +5821,9 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
> goto out;
> }
> folio_copy(page_folio(page), page_folio(*pagep));
What if we changed that folio_copy() to?
copy_user_huge_page(page, *pagep, dst_addr, dst_vma,
pages_per_huge_page(h));
Seems like that would take care of the flush_dcache_page and it would be
backportable.
Of course, Matthew may hate the idea. Not sure if there are any plans to
convert copy_user_huge_page to use folio type as it has some special hinting
logic.
--
Mike Kravetz
> + nr = compound_nr(page);
> + for (i = 0; i < nr; i++)
> + flush_dcache_page(page + i);
> put_page(*pagep);
> *pagep = NULL;
> }