On Tue, Aug 11, 2020 at 10:22:00PM +0200, Jann Horn wrote:
> On Tue, Aug 11, 2020 at 10:03 PM Peter Xu <peterx@xxxxxxxxxx> wrote:
> > On Tue, Aug 11, 2020 at 09:07:17PM +0200, Jann Horn wrote:
> > > On Tue, Aug 11, 2020 at 8:39 PM Peter Xu <peterx@xxxxxxxxxx> wrote:
> > > > Starting from commit 17839856fd58 ("gup: document and work around "COW can
> > > > break either way" issue", 2020-06-02), explicit copy-on-write behavior is
> > > > enforced for private gup pages even if it's a read-only. It is achieved by
> > > > always passing FOLL_WRITE to emulate a write.
> > > >
> > > > That should fix the COW issue that we were facing, however above commit could
> > > > also break userfaultfd-wp and applications like umapsort [1,2].
> > > >
> > > > One general routine of umap-like program is: userspace library will manage page
> > > > allocations, and it will evict the least recently used pages from memory to
> > > > external storages (e.g., file systems). Below are the general steps to evict
> > > > an in-memory page in the uffd service thread when the page pool is full:
> > > >
> > > > (1) UFFDIO_WRITEPROTECT with mode=WP on some to-be-evicted page P, so that
> > > > further writes to page P will block (keep page P clean)
> > > > (2) Copy page P to external storage (e.g. file system)
> > > > (3) MADV_DONTNEED to evict page P
> > > >
> > > > Here step (1) makes sure that the page to dump will always be up-to-date, so
> > > > that the page snapshot in the file system is consistent with the one that was
> > > > in the memory. However with commit 17839856fd58, step (2) can potentially hang
> > > > itself because e.g. if we use write() to a file system fd to dump the page
> > > > data, that will be a translated read gup request in the file system driver to
> > > > read the page content, then the read gup will be translated to a write gup due
> > > > to the new enforced COW behavior. This write gup will further trigger
> > > > handle_userfault() and hang the uffd service thread itself.
> > > >
> > > > I think the problem will go away too if we replace the write() to the file
> > > > system into a memory write to a mmaped region in the userspace library, because
> > > > normal page faults will not enforce COW, only gup is affected. However we
> > > > cannot forbid users to use write() or any form of kernel level read gup.
> > > >
> > > > One solution is actually already mentioned in commit 17839856fd58, which is to
> > > > provide an explicit BREAK_COW scemantics for enforced COW. Then we can still
> > > > use FAULT_FLAG_WRITE to identify whether this is a "real write request" or an
> > > > "enfornced COW (read) request".
> > > >
> > > > With the enforced COW, we also need to inherit UFFD_WP bit during COW because
> > > > now COW can happen with UFFD_WP enabled (previously, it cannot).
> [...]
> > > > @@ -1076,7 +1078,7 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> > > > }
> > > > if (is_vm_hugetlb_page(vma)) {
> > > > if (should_force_cow_break(vma, foll_flags))
> > > > - foll_flags |= FOLL_WRITE;
> > > > + foll_flags |= FOLL_BREAK_COW;
> > >
> > > How does this interact with the FOLL_WRITE check in follow_page_pte()?
> > > If we want the COW to be broken, follow_page_pte() would have to treat
> > > FOLL_BREAK_COW similarly to FOLL_WRITE, right?
> >
> > Good point... I did checked follow_page_mask() that FOLL_COW will still be set
> > correctly after applying the patch, though I forgot the FOLL_WRITE part.
> >
> > Does below look good to you?
> >
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 9d1f44b01165..f4f2a69c6fe7 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -439,7 +439,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
> > }
> > if ((flags & FOLL_NUMA) && pte_protnone(pte))
> > goto no_page;
> > - if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
> > + if ((flags & (FOLL_WRITE | FOLL_BREAK_COW)) &&
> > + !can_follow_write_pte(pte, flags)) {
> > pte_unmap_unlock(ptep, ptl);
> > return NULL;
> > }
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 4f192efef37c..edbd42c9d576 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1340,7 +1340,8 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
> >
> > assert_spin_locked(pmd_lockptr(mm, pmd));
> >
> > - if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
> > + if (flags & (FOLL_WRITE | FOLL_BREAK_COW) &&
> > + !can_follow_write_pmd(*pmd, flags))
> > goto out;
> >
> > /* Avoid dumping huge zero page */
>
> Well, I don't see anything immediately wrong with it, at least. Not
> that that means much...
>
> Although in addition to the normal-page path and the transhuge path,
> you'll probably also have to make the same change in the hugetlb path.
> I guess you may have to grep through all the uses of FOLL_WRITE, as
> Linus suggested, to see if there are any other missing spots.
Right. Moreover, I feel like the enforced cow is not completely done in
hugetlbfs code even without this patch. E.g., it lacks the proper return of
VM_FAULT_WRITE in hugetlb_cow(), and also the further convertion logics to
translate that into FOLL_COW (which, iiuc, should probably be done in
follow_hugetlb_page()).
I quickly went over the other FOLL_WRITE references and I didn't see any other
suspicious spots besides hugetlb (I only looked at the places that can be
called by __get_user_pages() though; that's the only place we set
FOLL_BREAK_COW after all). At the meantime we ignored the fast gups for strict
breaking of cow always, so those ones seem ok too.
Thanks,
--
Peter Xu
