Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Peter Xu <peterx@redhat.com>
To:     linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc:     Jason Gunthorpe <jgg@ziepe.ca>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jan Kara <jack@suse.cz>, Michal Hocko <mhocko@suse.com>,
        Kirill Tkhai <ktkhai@virtuozzo.com>,
        Kirill Shutemov <kirill@shutemov.name>,
        Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>,
        Christoph Hellwig <hch@lst.de>,
        Andrea Arcangeli <aarcange@redhat.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Leon Romanovsky <leonro@nvidia.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jann Horn <jannh@google.com>
Subject: [PATCH 0/5] mm: Break COW for pinned pages during fork()
Date:   Mon, 21 Sep 2020 17:17:39 -0400
Message-Id: <20200921211744.24758-1-peterx@redhat.com>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Finally I start to post formal patches because it's growing.  And also sinc=
e=0D
we've discussed quite some issues already, so I feel like it's clearer on w=
hat=0D
we need to do, and how.=0D
=0D
This series is majorly inspired by the previous discussion on the list [1],=
=0D
starting from the report from Jason on the rdma test failure.  Linus propos=
ed=0D
the solution, which seems to be a very nice approach to avoid the breakage =
of=0D
userspace apps that didn't use MADV_DONTFORK properly before.  More informa=
tion=0D
can be found in that thread too.=0D
=0D
I believe the initial plan was to consider merging something like this for=
=0D
rc7/rc8.  However now I'm not sure due to the fact that the code change in=
=0D
copy_pte_range() is probably more than expected, so it can be with some ris=
k.=0D
I'll leave this question to the reviewers...=0D
=0D
I tested it myself with fork() after vfio pinning a bunch of device pages, =
and=0D
I verified that the new copy pte logic worked as expected at least in the m=
ost=0D
general path.  However I didn't test thp case yet because afaict vfio does =
not=0D
support thp backed dma pages.  Luckily, the pmd/pud thp patch is much more=
=0D
straightforward than the pte one, so hopefully it can be directly verified =
by=0D
some code review plus some more heavy-weight rdma tests.=0D
=0D
Patch 1:      Introduce mm.has_pinned (as single patch as suggested by Jaso=
n)=0D
Patch 2-3:    Some slight rework on copy_page_range() path as preparation=0D
Patch 4:      Early cow solution for pte copy for pinned pages=0D
Patch 5:      Same as above, but for thp (pmd/pud).=0D
=0D
Hugetlbfs fix is still missing, but as planned, that's not urgent so we can=
=0D
work upon.  Comments greatly welcomed.=0D
=0D
Thanks.=0D
=0D
Peter Xu (5):=0D
  mm: Introduce mm_struct.has_pinned=0D
  mm/fork: Pass new vma pointer into copy_page_range()=0D
  mm: Rework return value for copy_one_pte()=0D
  mm: Do early cow for pinned pages during fork() for ptes=0D
  mm/thp: Split huge pmds/puds if they're pinned when fork()=0D
=0D
 include/linux/mm.h       |   2 +-=0D
 include/linux/mm_types.h |  10 ++=0D
 kernel/fork.c            |   3 +-=0D
 mm/gup.c                 |   6 ++=0D
 mm/huge_memory.c         |  26 +++++=0D
 mm/memory.c              | 226 +++++++++++++++++++++++++++++++++++----=0D
 6 files changed, 248 insertions(+), 25 deletions(-)=0D
=0D
-- =0D
2.26.2=0D
=0D