[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d78d6e56-1879-94c8-dc28-06431e583a77@oracle.com>
Date: Wed, 9 Feb 2022 11:07:07 -0800
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Muchun Song <songmuchun@...edance.com>, akpm@...ux-foundation.org,
zi.yan@...rutgers.edu, kirill.shutemov@...ux.intel.com,
rientjes@...gle.com, lars.persson@...s.com, ziy@...dia.com
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
duanxiongchun@...edance.com, fam.zheng@...edance.com
Subject: Re: [PATCH v4 3/5] mm: hugetlb: fix missing cache flush in
copy_huge_page_from_user()
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@...cle.com>
--
Mike Kravetz
>
> Fixes: fa4d75c1de13 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support")
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> ---
> mm/memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> 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;
Powered by blists - more mailing lists