| Message ID | 20220208073617.70342-4-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Fix some cache flush bugs | expand |
On 2/7/22 23:36, Muchun Song wrote: > The userfaultfd calls copy_huge_page_from_user() which does not do > any cache flushing for the target page. Then the target page will > be mapped to the user space with a different address (user address), > which might have an alias issue with the kernel address used to copy > the data from the user to. Fix this issue by flushing dcache in > copy_huge_page_from_user(). Quick question. Should this also be done for the non-hugetlb case? Take a look at the routines __mcopy_atomic() and mcopy_atomic_pte(). Or, is that somehow handled? For this change, Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
On Thu, Feb 10, 2022 at 3:07 AM Mike Kravetz <mike.kravetz@oracle.com> wrote: > > On 2/7/22 23:36, Muchun Song wrote: > > The userfaultfd calls copy_huge_page_from_user() which does not do > > any cache flushing for the target page. Then the target page will > > be mapped to the user space with a different address (user address), > > which might have an alias issue with the kernel address used to copy > > the data from the user to. Fix this issue by flushing dcache in > > copy_huge_page_from_user(). > > Quick question. > > Should this also be done for the non-hugetlb case? Take a look at the > routines __mcopy_atomic() and mcopy_atomic_pte(). Or, is that somehow > handled? Actually, you are right. __mcopy_atomic() and mcopy_atomic_pte() should also be fixed. And shmem_mfill_atomic_pte() also should be fixed. I'll fix those places in the next version. Thanks. > > For this change, > Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Thanks Mike.
diff --git a/mm/memory.c b/mm/memory.c index e8ce066be5f2..eb027da68aa7 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5405,6 +5405,8 @@ long copy_huge_page_from_user(struct page *dst_page, if (rc) break; + flush_dcache_page(subpage); + cond_resched(); } return ret_val;
The userfaultfd calls copy_huge_page_from_user() which does not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this issue by flushing dcache in copy_huge_page_from_user(). Fixes: fa4d75c1de13 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support") Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- mm/memory.c | 2 ++ 1 file changed, 2 insertions(+)