Messages in this thread | | | Subject | Re: [PATCH] mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte | From | Miaohe Lin <> | Date | Wed, 13 Jul 2022 10:10:56 +0800 |
| |
On 2022/7/13 1:39, Mike Kravetz wrote: > On 07/12/22 21:05, Miaohe Lin wrote: >> In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page >> cache are installed in the ptes. But hugepage_add_new_anon_rmap is called >> for them mistakenly because they're not vm_shared. This will corrupt the >> page->mapping used by page cache code. >> >> Fixes: f619147104c8 ("userfaultfd: add UFFDIO_CONTINUE ioctl") >> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> >> --- >> mm/hugetlb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > This looks correct to me. > > Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Many thanks for review.
> > However, I am having a hard time wrapping my head around how UFFDIO_CONTINUE > should work on non-anon private mappings. For example, a private mapping of > a hugetlbfs file. I think we just map the page in the file/cache and do not > set the write bit in the pte. So, yes we would want page_dup_file_rmap() > in this case as shown below.
+1
> > Adding Axel and Peter on Cc: as they were more involved in adding that code > and the design of UFFDIO_CONTINUE.
That would be really helpful.
Thanks.
>
| |