[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMZfGtUTj-r-sO3YRfyEhvR1mKYxi6kXx+ZZPVYjV3AhAMdh1g@mail.gmail.com>
Date: Thu, 10 Feb 2022 15:19:57 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Mike Kravetz <mike.kravetz@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, zi.yan@...rutgers.edu,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Lars Persson <lars.persson@...s.com>, Zi Yan <ziy@...dia.com>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Xiongchun duan <duanxiongchun@...edance.com>,
Fam Zheng <fam.zheng@...edance.com>
Subject: Re: [PATCH v4 3/5] mm: hugetlb: fix missing cache flush in copy_huge_page_from_user()
On Thu, Feb 10, 2022 at 3:07 AM Mike Kravetz <mike.kravetz@...cle.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@...cle.com>
Thanks Mike.
Powered by blists - more mailing lists