From: Peter Xu <peterx@redhat.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: David Hildenbrand <david@redhat.com>,
Hugh Dickins <hughd@google.com>, Maya Gokhale <gokhale2@llnl.gov>,
Jerome Glisse <jglisse@redhat.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
Johannes Weiner <hannes@cmpxchg.org>,
peterx@redhat.com, Martin Cracauer <cracauer@cons.org>,
Shaohua Li <shli@fb.com>,
Denis Plotnikov <dplotnikov@virtuozzo.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Marty McFadden <mcfadden8@llnl.gov>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Mel Gorman <mgorman@suse.de>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: [PATCH v4 14/27] userfaultfd: wp: handle COW properly for uffd-wp
Date: Fri, 26 Apr 2019 12:51:38 +0800 [thread overview]
Message-ID: <20190426045151.19556-15-peterx@redhat.com> (raw)
In-Reply-To: <20190426045151.19556-1-peterx@redhat.com>
This allows uffd-wp to support write-protected pages for COW.
For example, the uffd write-protected PTE could also be write-protected
by other usages like COW or zero pages. When that happens, we can't
simply set the write bit in the PTE since otherwise it'll change the
content of every single reference to the page. Instead, we should do
the COW first if necessary, then handle the uffd-wp fault.
To correctly copy the page, we'll also need to carry over the
_PAGE_UFFD_WP bit if it was set in the original PTE.
For huge PMDs, we just simply split the huge PMDs where we want to
resolve an uffd-wp page fault always. That matches what we do with
general huge PMD write protections. In that way, we resolved the huge
PMD copy-on-write issue into PTE copy-on-write.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
mm/memory.c | 5 ++++-
mm/mprotect.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index ab98a1eb4702..965d974bb9bd 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2299,7 +2299,10 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
}
flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
entry = mk_pte(new_page, vma->vm_page_prot);
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
+ if (pte_uffd_wp(vmf->orig_pte))
+ entry = pte_mkuffd_wp(entry);
+ else
+ entry = maybe_mkwrite(pte_mkdirty(entry), vma);
/*
* Clear the pte entry and flush it first, before updating the
* pte with the new entry. This will avoid a race condition
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 732d9b6d1d21..1f40662182f8 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -73,18 +73,18 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
flush_tlb_batched_pending(vma->vm_mm);
arch_enter_lazy_mmu_mode();
do {
+retry_pte:
oldpte = *pte;
if (pte_present(oldpte)) {
pte_t ptent;
bool preserve_write = prot_numa && pte_write(oldpte);
+ struct page *page;
/*
* Avoid trapping faults against the zero or KSM
* pages. See similar comment in change_huge_pmd.
*/
if (prot_numa) {
- struct page *page;
-
page = vm_normal_page(vma, addr, oldpte);
if (!page || PageKsm(page))
continue;
@@ -114,6 +114,45 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
continue;
}
+ /*
+ * Detect whether we'll need to COW before
+ * resolving an uffd-wp fault. Note that this
+ * includes detection of the zero page (where
+ * page==NULL)
+ */
+ if (uffd_wp_resolve) {
+ struct vm_fault vmf = {
+ .vma = vma,
+ .address = addr & PAGE_MASK,
+ .orig_pte = oldpte,
+ .pmd = pmd,
+ .pte = pte,
+ .ptl = ptl,
+ };
+ vm_fault_t ret;
+
+ /* If the fault is resolved already, skip */
+ if (!pte_uffd_wp(*pte))
+ continue;
+
+ arch_leave_lazy_mmu_mode();
+ /* With PTE lock held */
+ ret = do_wp_page_cont(&vmf);
+ if (ret != VM_FAULT_WRITE && ret != 0)
+ /* Probably OOM */
+ return pages;
+ pte = pte_offset_map_lock(vma->vm_mm, pmd,
+ addr, &ptl);
+ arch_enter_lazy_mmu_mode();
+ if (ret == 0 || !pte_present(*pte))
+ /*
+ * This PTE could have been modified
+ * during or after COW before taking
+ * the lock; retry.
+ */
+ goto retry_pte;
+ }
+
oldpte = ptep_modify_prot_start(vma, addr, pte);
ptent = pte_modify(oldpte, newprot);
if (preserve_write)
@@ -183,6 +222,7 @@ static inline unsigned long change_pmd_range(struct vm_area_struct *vma,
unsigned long pages = 0;
unsigned long nr_huge_updates = 0;
struct mmu_notifier_range range;
+ bool uffd_wp_resolve = cp_flags & MM_CP_UFFD_WP_RESOLVE;
range.start = 0;
@@ -202,7 +242,16 @@ static inline unsigned long change_pmd_range(struct vm_area_struct *vma,
}
if (is_swap_pmd(*pmd) || pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) {
- if (next - addr != HPAGE_PMD_SIZE) {
+ /*
+ * When resolving an userfaultfd write
+ * protection fault, it's not easy to identify
+ * whether a THP is shared with others and
+ * whether we'll need to do copy-on-write, so
+ * just split it always for now to simply the
+ * procedure. And that's the policy too for
+ * general THP write-protect in af9e4d5f2de2.
+ */
+ if (next - addr != HPAGE_PMD_SIZE || uffd_wp_resolve) {
__split_huge_pmd(vma, pmd, addr, false, NULL);
} else {
int nr_ptes = change_huge_pmd(vma, pmd, addr,
--
2.17.1
next prev parent reply other threads:[~2019-04-26 4:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 4:51 [PATCH v4 00/27] userfaultfd: write protection support Peter Xu
2019-04-26 4:51 ` [PATCH v4 01/27] mm: gup: rename "nonblocking" to "locked" where proper Peter Xu
2019-04-26 4:51 ` [PATCH v4 02/27] mm: userfault: return VM_FAULT_RETRY on signals Peter Xu
2019-04-26 4:51 ` [PATCH v4 03/27] userfaultfd: don't retake mmap_sem to emulate NOPAGE Peter Xu
2019-04-26 4:51 ` [PATCH v4 04/27] mm: allow VM_FAULT_RETRY for multiple times Peter Xu
2019-04-26 4:51 ` [PATCH v4 05/27] mm: gup: " Peter Xu
2019-04-26 4:51 ` [PATCH v4 06/27] userfaultfd: wp: add helper for writeprotect check Peter Xu
2019-04-26 4:51 ` [PATCH v4 07/27] userfaultfd: wp: hook userfault handler to write protection fault Peter Xu
2019-04-26 4:51 ` [PATCH v4 08/27] userfaultfd: wp: add WP pagetable tracking to x86 Peter Xu
2019-04-26 4:51 ` [PATCH v4 09/27] userfaultfd: wp: userfaultfd_pte/huge_pmd_wp() helpers Peter Xu
2019-04-26 4:51 ` [PATCH v4 10/27] userfaultfd: wp: add UFFDIO_COPY_MODE_WP Peter Xu
2019-04-26 4:51 ` [PATCH v4 11/27] mm: merge parameters for change_protection() Peter Xu
2019-04-26 4:51 ` [PATCH v4 12/27] userfaultfd: wp: apply _PAGE_UFFD_WP bit Peter Xu
2019-04-26 4:51 ` [PATCH v4 13/27] mm: introduce do_wp_page_cont() Peter Xu
2019-04-26 4:51 ` Peter Xu [this message]
2019-04-26 4:51 ` [PATCH v4 15/27] userfaultfd: wp: drop _PAGE_UFFD_WP properly when fork Peter Xu
2019-04-26 4:51 ` [PATCH v4 16/27] userfaultfd: wp: add pmd_swp_*uffd_wp() helpers Peter Xu
2019-04-26 4:51 ` [PATCH v4 17/27] userfaultfd: wp: support swap and page migration Peter Xu
2019-04-26 4:51 ` [PATCH v4 18/27] khugepaged: skip collapse if uffd-wp detected Peter Xu
2019-04-26 4:51 ` [PATCH v4 19/27] userfaultfd: introduce helper vma_find_uffd Peter Xu
2019-04-26 4:51 ` [PATCH v4 20/27] userfaultfd: wp: support write protection for userfault vma range Peter Xu
2019-04-26 4:51 ` [PATCH v4 21/27] userfaultfd: wp: add the writeprotect API to userfaultfd ioctl Peter Xu
2019-04-26 4:51 ` [PATCH v4 22/27] userfaultfd: wp: enabled write protection in userfaultfd API Peter Xu
2019-04-26 4:51 ` [PATCH v4 23/27] userfaultfd: wp: don't wake up when doing write protect Peter Xu
2019-04-26 4:51 ` [PATCH v4 24/27] userfaultfd: wp: UFFDIO_REGISTER_MODE_WP documentation update Peter Xu
2019-04-26 4:51 ` [PATCH v4 25/27] userfaultfd: wp: declare _UFFDIO_WRITEPROTECT conditionally Peter Xu
2019-04-26 4:51 ` [PATCH v4 26/27] userfaultfd: selftests: refactor statistics Peter Xu
2019-04-26 4:51 ` [PATCH v4 27/27] userfaultfd: selftests: add write-protect test Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190426045151.19556-15-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=cracauer@cons.org \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=dplotnikov@virtuozzo.com \
--cc=gokhale2@llnl.gov \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jglisse@redhat.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcfadden8@llnl.gov \
--cc=mgorman@suse.de \
--cc=mike.kravetz@oracle.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=shli@fb.com \
--cc=xemul@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox