linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 0/2] mm/uffd: Add feature bit UFFD_FEATURE_WP_UNPOPULATED
@ 2023-03-09 22:37 Peter Xu
  2023-03-09 22:37 ` [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Peter Xu
  2023-03-09 22:37 ` [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED Peter Xu
  0 siblings, 2 replies; 9+ messages in thread
From: Peter Xu @ 2023-03-09 22:37 UTC (permalink / raw)
  To: linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	David Hildenbrand, Mike Rapoport, Andrea Arcangeli, peterx,
	Andrew Morton

v1: https://lore.kernel.org/r/20230215210257.224243-1-peterx@redhat.com
v2: https://lore.kernel.org/r/20230227230044.1596744-1-peterx@redhat.com
v3: https://lore.kernel.org/r/20230306213925.617814-1-peterx@redhat.com

v4:
- s/handle_pte_missing/do_pte_missing/, fix spellings, etc. [David]
- Add a helper userfaultfd_wp_use_markers() [David]
- Update userfaultfd.rst describing the new feature bit

The new feature bit will make anonymous memory acts the same like file
memory on userfaultfd-wp in that it'll also wr-protect none ptes.

It can be useful in two cases:

(1) Uffd-wp app that needs to wr-protect none ptes like QEMU snapshot, so
    pre-fault can be replaced by enabling this flag and speed up protections

(2) It helps to implement async uffd-wp mode that Muhammad is working on [1]

It's debateable whether this is the most ideal solution because with the
new feature bit set, wr-protect none pte needs to pre-populate the pgtables
to the last level (PAGE_SIZE).  But it seems fine so far to service either
purpose above, so we can leave optimizations for later.

The series brings pte markers to anonymous memory too.  There's some change
in the common mm code path in the 1st patch, great to have some eye looking
at it, but hopefully they're still relatively straightforward.

Thanks,

[1] https://lore.kernel.org/all/Y+v2HJ8+3i%2FKzDBu@x1n/

Peter Xu (2):
  mm/uffd: UFFD_FEATURE_WP_UNPOPULATED
  selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED

 Documentation/admin-guide/mm/userfaultfd.rst | 17 ++++++
 fs/userfaultfd.c                             | 16 ++++++
 include/linux/mm_inline.h                    |  6 +++
 include/linux/userfaultfd_k.h                | 23 ++++++++
 include/uapi/linux/userfaultfd.h             | 10 +++-
 mm/memory.c                                  | 56 +++++++++++++++-----
 mm/mprotect.c                                | 51 ++++++++++++++----
 tools/testing/selftests/mm/userfaultfd.c     | 45 +++++++++++++++-
 8 files changed, 197 insertions(+), 27 deletions(-)

-- 
2.39.1



^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED
  2023-03-09 22:37 [PATCH v4 0/2] mm/uffd: Add feature bit UFFD_FEATURE_WP_UNPOPULATED Peter Xu
@ 2023-03-09 22:37 ` Peter Xu
  2023-03-20 10:21   ` David Hildenbrand
  2023-03-24 15:21   ` Peter Xu
  2023-03-09 22:37 ` [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED Peter Xu
  1 sibling, 2 replies; 9+ messages in thread
From: Peter Xu @ 2023-03-09 22:37 UTC (permalink / raw)
  To: linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	David Hildenbrand, Mike Rapoport, Andrea Arcangeli, peterx,
	Andrew Morton

This is a new feature that controls how uffd-wp handles none ptes.  When
it's set, the kernel will handle anonymous memory the same way as file
memory, by allowing the user to wr-protect unpopulated ptes.

File memories handles none ptes consistently by allowing wr-protecting of
none ptes because of the unawareness of page cache being exist or not.  For
anonymous it was not as persistent because we used to assume that we don't
need protections on none ptes or known zero pages.

One use case of such a feature bit was VM live snapshot, where if without
wr-protecting empty ptes the snapshot can contain random rubbish in the
holes of the anonymous memory, which can cause misbehave of the guest when
the guest OS assumes the pages should be all zeros.

QEMU worked it around by pre-populate the section with reads to fill in
zero page entries before starting the whole snapshot process [1].

Recently there's another need raised on using userfaultfd wr-protect for
detecting dirty pages (to replace soft-dirty in some cases) [2].  In that
case if without being able to wr-protect none ptes by default, the dirty
info can get lost, since we cannot treat every none pte to be dirty (the
current design is identify a page dirty based on uffd-wp bit being cleared).

In general, we want to be able to wr-protect empty ptes too even for
anonymous.

This patch implements UFFD_FEATURE_WP_UNPOPULATED so that it'll make
uffd-wp handling on none ptes being consistent no matter what the memory
type is underneath.  It doesn't have any impact on file memories so far
because we already have pte markers taking care of that.  So it only
affects anonymous.

The feature bit is by default off, so the old behavior will be maintained.
Sometimes it may be wanted because the wr-protect of none ptes will contain
overheads not only during UFFDIO_WRITEPROTECT (by applying pte markers to
anonymous), but also on creating the pgtables to store the pte markers. So
there's potentially less chance of using thp on the first fault for a none
pmd or larger than a pmd.

The major implementation part is teaching the whole kernel to understand
pte markers even for anonymously mapped ranges, meanwhile allowing the
UFFDIO_WRITEPROTECT ioctl to apply pte markers for anonymous too when the
new feature bit is set.

Note that even if the patch subject starts with mm/uffd, there're a few
small refactors to major mm path of handling anonymous page faults. But
they should be straightforward.

With WP_UNPOPUATED, application like QEMU can avoid pre-read faults all the
memory before wr-protect during taking a live snapshot.  Quotting from
Muhammad's test result here [3] based on a simple program [4]:

  (1) With huge page disabled
  echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
  ./uffd_wp_perf
  Test DEFAULT: 4
  Test PRE-READ: 1111453 (pre-fault 1101011)
  Test MADVISE: 278276 (pre-fault 266378)
  Test WP-UNPOPULATE: 11712

  (2) With Huge page enabled
  echo always > /sys/kernel/mm/transparent_hugepage/enabled
  ./uffd_wp_perf
  Test DEFAULT: 4
  Test PRE-READ: 22521 (pre-fault 22348)
  Test MADVISE: 4909 (pre-fault 4743)
  Test WP-UNPOPULATE: 14448

There'll be a great perf boost for no-thp case, while for thp enabled with
extreme case of all-thp-zero WP_UNPOPULATED can be slower than MADVISE, but
that's low possibility in reality, also the overhead was not reduced but
postponed until a follow up write on any huge zero thp, so potentially it
is faster by making the follow up writes slower.

[1] https://lore.kernel.org/all/20210401092226.102804-4-andrey.gruzdev@virtuozzo.com/
[2] https://lore.kernel.org/all/Y+v2HJ8+3i%2FKzDBu@x1n/
[3] https://lore.kernel.org/all/d0eb0a13-16dc-1ac1-653a-78b7273781e3@collabora.com/
[4] https://github.com/xzpeter/clibs/blob/master/uffd-test/uffd-wp-perf.c

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 Documentation/admin-guide/mm/userfaultfd.rst | 17 ++++++
 fs/userfaultfd.c                             | 16 ++++++
 include/linux/mm_inline.h                    |  6 +++
 include/linux/userfaultfd_k.h                | 23 ++++++++
 include/uapi/linux/userfaultfd.h             | 10 +++-
 mm/memory.c                                  | 56 +++++++++++++++-----
 mm/mprotect.c                                | 51 ++++++++++++++----
 7 files changed, 154 insertions(+), 25 deletions(-)

diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 7dc823b56ca4..c86b56c95ea6 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -219,6 +219,23 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
 you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
 used.
 
+Userfaultfd write-protect mode currently behave differently on none ptes
+(when e.g. page is missing) over different types of memories.
+
+For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
+(e.g. when pages are missing and not populated).  For file-backed memories
+like shmem and hugetlbfs, none ptes will be write protected just like a
+present pte.  In other words, there will be a userfaultfd write fault
+message generated when writting to a missing page on file typed memories,
+as long as the page range was write-protected before.  Such a message will
+not be generated on anonymous memories by default.
+
+If the application wants to be able to write protect none ptes on anonymous
+memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
+newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
+and set the feature bit in advance to make sure none ptes will also be
+write protected even upon anonymous memory.
+
 QEMU/KVM
 ========
 
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 44d1ee429eb0..881e9c82b9d1 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -108,6 +108,21 @@ static bool userfaultfd_is_initialized(struct userfaultfd_ctx *ctx)
 	return ctx->features & UFFD_FEATURE_INITIALIZED;
 }
 
+/*
+ * Whether WP_UNPOPULATED is enabled on the uffd context.  It is only
+ * meaningful when userfaultfd_wp()==true on the vma and when it's
+ * anonymous.
+ */
+bool userfaultfd_wp_unpopulated(struct vm_area_struct *vma)
+{
+	struct userfaultfd_ctx *ctx = vma->vm_userfaultfd_ctx.ctx;
+
+	if (!ctx)
+		return false;
+
+	return ctx->features & UFFD_FEATURE_WP_UNPOPULATED;
+}
+
 static void userfaultfd_set_vm_flags(struct vm_area_struct *vma,
 				     vm_flags_t flags)
 {
@@ -1971,6 +1986,7 @@ static int userfaultfd_api(struct userfaultfd_ctx *ctx,
 #endif
 #ifndef CONFIG_PTE_MARKER_UFFD_WP
 	uffdio_api.features &= ~UFFD_FEATURE_WP_HUGETLBFS_SHMEM;
+	uffdio_api.features &= ~UFFD_FEATURE_WP_UNPOPULATED;
 #endif
 	uffdio_api.ioctls = UFFD_API_IOCTLS;
 	ret = -EFAULT;
diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
index de1e622dd366..0e1d239a882c 100644
--- a/include/linux/mm_inline.h
+++ b/include/linux/mm_inline.h
@@ -557,6 +557,12 @@ pte_install_uffd_wp_if_needed(struct vm_area_struct *vma, unsigned long addr,
 	/* The current status of the pte should be "cleared" before calling */
 	WARN_ON_ONCE(!pte_none(*pte));
 
+	/*
+	 * NOTE: userfaultfd_wp_unpopulated() doesn't need this whole
+	 * thing, because when zapping either it means it's dropping the
+	 * page, or in TTU where the present pte will be quickly replaced
+	 * with a swap pte.  There's no way of leaking the bit.
+	 */
 	if (vma_is_anonymous(vma) || !userfaultfd_wp(vma))
 		return;
 
diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
index 3767f18114ef..0cf8880219da 100644
--- a/include/linux/userfaultfd_k.h
+++ b/include/linux/userfaultfd_k.h
@@ -179,6 +179,7 @@ extern int userfaultfd_unmap_prep(struct mm_struct *mm, unsigned long start,
 				  unsigned long end, struct list_head *uf);
 extern void userfaultfd_unmap_complete(struct mm_struct *mm,
 				       struct list_head *uf);
+extern bool userfaultfd_wp_unpopulated(struct vm_area_struct *vma);
 
 #else /* CONFIG_USERFAULTFD */
 
@@ -274,8 +275,30 @@ static inline bool uffd_disable_fault_around(struct vm_area_struct *vma)
 	return false;
 }
 
+static inline bool userfaultfd_wp_unpopulated(struct vm_area_struct *vma)
+{
+	return false;
+}
+
 #endif /* CONFIG_USERFAULTFD */
 
+static inline bool userfaultfd_wp_use_markers(struct vm_area_struct *vma)
+{
+	/* Only wr-protect mode uses pte markers */
+	if (!userfaultfd_wp(vma))
+		return false;
+
+	/* File-based uffd-wp always need markers */
+	if (!vma_is_anonymous(vma))
+		return true;
+
+	/*
+	 * Anonymous uffd-wp only needs the markers if WP_UNPOPULATED
+	 * enabled (to apply markers on zero pages).
+	 */
+	return userfaultfd_wp_unpopulated(vma);
+}
+
 static inline bool pte_marker_entry_uffd_wp(swp_entry_t entry)
 {
 #ifdef CONFIG_PTE_MARKER_UFFD_WP
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index 005e5e306266..90c958952bfc 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -38,7 +38,8 @@
 			   UFFD_FEATURE_MINOR_HUGETLBFS |	\
 			   UFFD_FEATURE_MINOR_SHMEM |		\
 			   UFFD_FEATURE_EXACT_ADDRESS |		\
-			   UFFD_FEATURE_WP_HUGETLBFS_SHMEM)
+			   UFFD_FEATURE_WP_HUGETLBFS_SHMEM |	\
+			   UFFD_FEATURE_WP_UNPOPULATED)
 #define UFFD_API_IOCTLS				\
 	((__u64)1 << _UFFDIO_REGISTER |		\
 	 (__u64)1 << _UFFDIO_UNREGISTER |	\
@@ -203,6 +204,12 @@ struct uffdio_api {
 	 *
 	 * UFFD_FEATURE_WP_HUGETLBFS_SHMEM indicates that userfaultfd
 	 * write-protection mode is supported on both shmem and hugetlbfs.
+	 *
+	 * UFFD_FEATURE_WP_UNPOPULATED indicates that userfaultfd
+	 * write-protection mode will always apply to unpopulated pages
+	 * (i.e. empty ptes).  This will be the default behavior for shmem
+	 * & hugetlbfs, so this flag only affects anonymous memory behavior
+	 * when userfault write-protection mode is registered.
 	 */
 #define UFFD_FEATURE_PAGEFAULT_FLAG_WP		(1<<0)
 #define UFFD_FEATURE_EVENT_FORK			(1<<1)
@@ -217,6 +224,7 @@ struct uffdio_api {
 #define UFFD_FEATURE_MINOR_SHMEM		(1<<10)
 #define UFFD_FEATURE_EXACT_ADDRESS		(1<<11)
 #define UFFD_FEATURE_WP_HUGETLBFS_SHMEM		(1<<12)
+#define UFFD_FEATURE_WP_UNPOPULATED		(1<<13)
 	__u64 features;
 
 	__u64 ioctls;
diff --git a/mm/memory.c b/mm/memory.c
index 0adf23ea5416..8d73d3056348 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -104,6 +104,20 @@ EXPORT_SYMBOL(mem_map);
 #endif
 
 static vm_fault_t do_fault(struct vm_fault *vmf);
+static vm_fault_t do_anonymous_page(struct vm_fault *vmf);
+static bool vmf_pte_changed(struct vm_fault *vmf);
+
+/*
+ * Return true if the original pte was a uffd-wp pte marker (so the pte was
+ * wr-protected).
+ */
+static bool vmf_orig_pte_uffd_wp(struct vm_fault *vmf)
+{
+	if (!(vmf->flags & FAULT_FLAG_ORIG_PTE_VALID))
+		return false;
+
+	return pte_marker_uffd_wp(vmf->orig_pte);
+}
 
 /*
  * A number of key systems in x86 including ioremap() rely on the assumption
@@ -1350,6 +1364,10 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
 			      unsigned long addr, pte_t *pte,
 			      struct zap_details *details, pte_t pteval)
 {
+	/* Zap on anonymous always means dropping everything */
+	if (vma_is_anonymous(vma))
+		return;
+
 	if (zap_drop_file_uffd_wp(details))
 		return;
 
@@ -1456,8 +1474,12 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 				continue;
 			rss[mm_counter(page)]--;
 		} else if (pte_marker_entry_uffd_wp(entry)) {
-			/* Only drop the uffd-wp marker if explicitly requested */
-			if (!zap_drop_file_uffd_wp(details))
+			/*
+			 * For anon: always drop the marker; for file: only
+			 * drop the marker if explicitly requested.
+			 */
+			if (!vma_is_anonymous(vma) &&
+			    !zap_drop_file_uffd_wp(details))
 				continue;
 		} else if (is_hwpoison_entry(entry) ||
 			   is_swapin_error_entry(entry)) {
@@ -3624,6 +3646,14 @@ static vm_fault_t pte_marker_clear(struct vm_fault *vmf)
 	return 0;
 }
 
+static vm_fault_t do_pte_missing(struct vm_fault *vmf)
+{
+	if (vma_is_anonymous(vmf->vma))
+		return do_anonymous_page(vmf);
+	else
+		return do_fault(vmf);
+}
+
 /*
  * This is actually a page-missing access, but with uffd-wp special pte
  * installed.  It means this pte was wr-protected before being unmapped.
@@ -3634,11 +3664,10 @@ static vm_fault_t pte_marker_handle_uffd_wp(struct vm_fault *vmf)
 	 * Just in case there're leftover special ptes even after the region
 	 * got unregistered - we can simply clear them.
 	 */
-	if (unlikely(!userfaultfd_wp(vmf->vma) || vma_is_anonymous(vmf->vma)))
+	if (unlikely(!userfaultfd_wp(vmf->vma)))
 		return pte_marker_clear(vmf);
 
-	/* do_fault() can handle pte markers too like none pte */
-	return do_fault(vmf);
+	return do_pte_missing(vmf);
 }
 
 static vm_fault_t handle_pte_marker(struct vm_fault *vmf)
@@ -4008,6 +4037,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
  */
 static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 {
+	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
 	struct vm_area_struct *vma = vmf->vma;
 	struct folio *folio;
 	vm_fault_t ret = 0;
@@ -4041,7 +4071,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 						vma->vm_page_prot));
 		vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
 				vmf->address, &vmf->ptl);
-		if (!pte_none(*vmf->pte)) {
+		if (vmf_pte_changed(vmf)) {
 			update_mmu_tlb(vma, vmf->address, vmf->pte);
 			goto unlock;
 		}
@@ -4081,7 +4111,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 
 	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
 			&vmf->ptl);
-	if (!pte_none(*vmf->pte)) {
+	if (vmf_pte_changed(vmf)) {
 		update_mmu_tlb(vma, vmf->address, vmf->pte);
 		goto release;
 	}
@@ -4101,6 +4131,8 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	folio_add_new_anon_rmap(folio, vma, vmf->address);
 	folio_add_lru_vma(folio, vma);
 setpte:
+	if (uffd_wp)
+		entry = pte_mkuffd_wp(entry);
 	set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
 
 	/* No need to invalidate - it was non-present before */
@@ -4268,7 +4300,7 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
 void do_set_pte(struct vm_fault *vmf, struct page *page, unsigned long addr)
 {
 	struct vm_area_struct *vma = vmf->vma;
-	bool uffd_wp = pte_marker_uffd_wp(vmf->orig_pte);
+	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
 	bool write = vmf->flags & FAULT_FLAG_WRITE;
 	bool prefault = vmf->address != addr;
 	pte_t entry;
@@ -4915,12 +4947,8 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
 		}
 	}
 
-	if (!vmf->pte) {
-		if (vma_is_anonymous(vmf->vma))
-			return do_anonymous_page(vmf);
-		else
-			return do_fault(vmf);
-	}
+	if (!vmf->pte)
+		return do_pte_missing(vmf);
 
 	if (!pte_present(vmf->orig_pte))
 		return do_swap_page(vmf);
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 231929f119d9..455f7051098f 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -276,7 +276,15 @@ static long change_pte_range(struct mmu_gather *tlb,
 		} else {
 			/* It must be an none page, or what else?.. */
 			WARN_ON_ONCE(!pte_none(oldpte));
-			if (unlikely(uffd_wp && !vma_is_anonymous(vma))) {
+
+			/*
+			 * Nobody plays with any none ptes besides
+			 * userfaultfd when applying the protections.
+			 */
+			if (likely(!uffd_wp))
+				continue;
+
+			if (userfaultfd_wp_use_markers(vma)) {
 				/*
 				 * For file-backed mem, we need to be able to
 				 * wr-protect a none pte, because even if the
@@ -320,23 +328,46 @@ static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd)
 	return 0;
 }
 
-/* Return true if we're uffd wr-protecting file-backed memory, or false */
+/*
+ * Return true if we want to split huge thps in change protection
+ * procedure, false otherwise.
+ */
 static inline bool
-uffd_wp_protect_file(struct vm_area_struct *vma, unsigned long cp_flags)
+pgtable_split_needed(struct vm_area_struct *vma, unsigned long cp_flags)
 {
+	/*
+	 * pte markers only resides in pte level, if we need pte markers,
+	 * we need to split.  We cannot wr-protect shmem thp because file
+	 * thp is handled differently when split by erasing the pmd so far.
+	 */
 	return (cp_flags & MM_CP_UFFD_WP) && !vma_is_anonymous(vma);
 }
 
 /*
- * If wr-protecting the range for file-backed, populate pgtable for the case
- * when pgtable is empty but page cache exists.  When {pte|pmd|...}_alloc()
- * failed we treat it the same way as pgtable allocation failures during
- * page faults by kicking OOM and returning error.
+ * Return true if we want to populate pgtables in change protection
+ * procedure, false otherwise
+ */
+static inline bool
+pgtable_populate_needed(struct vm_area_struct *vma, unsigned long cp_flags)
+{
+	/* If not within ioctl(UFFDIO_WRITEPROTECT), then don't bother */
+	if (!(cp_flags & MM_CP_UFFD_WP))
+		return false;
+
+	/* Populate if the userfaultfd mode requires pte markers */
+	return userfaultfd_wp_use_markers(vma);
+}
+
+/*
+ * Populate the pgtable underneath for whatever reason if requested.
+ * When {pte|pmd|...}_alloc() failed we treat it the same way as pgtable
+ * allocation failures during page faults by kicking OOM and returning
+ * error.
  */
 #define  change_pmd_prepare(vma, pmd, cp_flags)				\
 	({								\
 		long err = 0;						\
-		if (unlikely(uffd_wp_protect_file(vma, cp_flags))) {	\
+		if (unlikely(pgtable_populate_needed(vma, cp_flags))) {	\
 			if (pte_alloc(vma->vm_mm, pmd))			\
 				err = -ENOMEM;				\
 		}							\
@@ -351,7 +382,7 @@ uffd_wp_protect_file(struct vm_area_struct *vma, unsigned long cp_flags)
 #define  change_prepare(vma, high, low, addr, cp_flags)			\
 	  ({								\
 		long err = 0;						\
-		if (unlikely(uffd_wp_protect_file(vma, cp_flags))) {	\
+		if (unlikely(pgtable_populate_needed(vma, cp_flags))) {	\
 			low##_t *p = low##_alloc(vma->vm_mm, high, addr); \
 			if (p == NULL)					\
 				err = -ENOMEM;				\
@@ -404,7 +435,7 @@ static inline long change_pmd_range(struct mmu_gather *tlb,
 
 		if (is_swap_pmd(*pmd) || pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) {
 			if ((next - addr != HPAGE_PMD_SIZE) ||
-			    uffd_wp_protect_file(vma, cp_flags)) {
+			    pgtable_split_needed(vma, cp_flags)) {
 				__split_huge_pmd(vma, pmd, addr, false, NULL);
 				/*
 				 * For file-backed, the pmd could have been
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED
  2023-03-09 22:37 [PATCH v4 0/2] mm/uffd: Add feature bit UFFD_FEATURE_WP_UNPOPULATED Peter Xu
  2023-03-09 22:37 ` [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Peter Xu
@ 2023-03-09 22:37 ` Peter Xu
  2023-03-20 10:25   ` David Hildenbrand
  1 sibling, 1 reply; 9+ messages in thread
From: Peter Xu @ 2023-03-09 22:37 UTC (permalink / raw)
  To: linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	David Hildenbrand, Mike Rapoport, Andrea Arcangeli, peterx,
	Andrew Morton

Enable it by default on the stress test, and add some smoke tests for the
pte markers on anonymous.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 tools/testing/selftests/mm/userfaultfd.c | 45 ++++++++++++++++++++++--
 1 file changed, 43 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mm/userfaultfd.c b/tools/testing/selftests/mm/userfaultfd.c
index 7f22844ed704..e030d63c031a 100644
--- a/tools/testing/selftests/mm/userfaultfd.c
+++ b/tools/testing/selftests/mm/userfaultfd.c
@@ -1444,6 +1444,43 @@ static int pagemap_test_fork(bool present)
 	return result;
 }
 
+static void userfaultfd_wp_unpopulated_test(int pagemap_fd)
+{
+	uint64_t value;
+
+	/* Test applying pte marker to anon unpopulated */
+	wp_range(uffd, (uint64_t)area_dst, page_size, true);
+	value = pagemap_read_vaddr(pagemap_fd, area_dst);
+	pagemap_check_wp(value, true);
+
+	/* Test unprotect on anon pte marker */
+	wp_range(uffd, (uint64_t)area_dst, page_size, false);
+	value = pagemap_read_vaddr(pagemap_fd, area_dst);
+	pagemap_check_wp(value, false);
+
+	/* Test zap on anon marker */
+	wp_range(uffd, (uint64_t)area_dst, page_size, true);
+	if (madvise(area_dst, page_size, MADV_DONTNEED))
+		err("madvise(MADV_DONTNEED) failed");
+	value = pagemap_read_vaddr(pagemap_fd, area_dst);
+	pagemap_check_wp(value, false);
+
+	/* Test fault in after marker removed */
+	*area_dst = 1;
+	value = pagemap_read_vaddr(pagemap_fd, area_dst);
+	pagemap_check_wp(value, false);
+	/* Drop it to make pte none again */
+	if (madvise(area_dst, page_size, MADV_DONTNEED))
+		err("madvise(MADV_DONTNEED) failed");
+
+	/* Test read-zero-page upon pte marker */
+	wp_range(uffd, (uint64_t)area_dst, page_size, true);
+	*(volatile char *)area_dst;
+	/* Drop it to make pte none again */
+	if (madvise(area_dst, page_size, MADV_DONTNEED))
+		err("madvise(MADV_DONTNEED) failed");
+}
+
 static void userfaultfd_pagemap_test(unsigned int test_pgsize)
 {
 	struct uffdio_register uffdio_register;
@@ -1462,7 +1499,7 @@ static void userfaultfd_pagemap_test(unsigned int test_pgsize)
 	/* Flush so it doesn't flush twice in parent/child later */
 	fflush(stdout);
 
-	uffd_test_ctx_init(0);
+	uffd_test_ctx_init(UFFD_FEATURE_WP_UNPOPULATED);
 
 	if (test_pgsize > page_size) {
 		/* This is a thp test */
@@ -1482,6 +1519,10 @@ static void userfaultfd_pagemap_test(unsigned int test_pgsize)
 
 	pagemap_fd = pagemap_open();
 
+	/* Smoke test WP_UNPOPULATED first when it's still empty */
+	if (test_pgsize == page_size)
+		userfaultfd_wp_unpopulated_test(pagemap_fd);
+
 	/* Touch the page */
 	*area_dst = 1;
 	wp_range(uffd, (uint64_t)area_dst, test_pgsize, true);
@@ -1526,7 +1567,7 @@ static int userfaultfd_stress(void)
 	struct uffdio_register uffdio_register;
 	struct uffd_stats uffd_stats[nr_cpus];
 
-	uffd_test_ctx_init(0);
+	uffd_test_ctx_init(UFFD_FEATURE_WP_UNPOPULATED);
 
 	if (posix_memalign(&area, page_size, page_size))
 		err("out of memory");
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED
  2023-03-09 22:37 ` [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Peter Xu
@ 2023-03-20 10:21   ` David Hildenbrand
  2023-03-20 14:41     ` Peter Xu
  2023-03-24 15:21   ` Peter Xu
  1 sibling, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2023-03-20 10:21 UTC (permalink / raw)
  To: Peter Xu, linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	Mike Rapoport, Andrea Arcangeli, Andrew Morton


>    (1) With huge page disabled
>    echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
>    ./uffd_wp_perf
>    Test DEFAULT: 4
>    Test PRE-READ: 1111453 (pre-fault 1101011)
>    Test MADVISE: 278276 (pre-fault 266378)

Thinking about it, I guess the biggest slowdown here is the "one fake 
pagefault at a time" handling.

>    Test WP-UNPOPULATE: 11712
> 
>    (2) With Huge page enabled
>    echo always > /sys/kernel/mm/transparent_hugepage/enabled
>    ./uffd_wp_perf
>    Test DEFAULT: 4
>    Test PRE-READ: 22521 (pre-fault 22348)
>    Test MADVISE: 4909 (pre-fault 4743)
>    Test WP-UNPOPULATE: 14448
> 
> There'll be a great perf boost for no-thp case, while for thp enabled with
> extreme case of all-thp-zero WP_UNPOPULATED can be slower than MADVISE, but
> that's low possibility in reality, also the overhead was not reduced but
> postponed until a follow up write on any huge zero thp, so potentially it
> is faster by making the follow up writes slower.
> 
> [1] https://lore.kernel.org/all/20210401092226.102804-4-andrey.gruzdev@virtuozzo.com/
> [2] https://lore.kernel.org/all/Y+v2HJ8+3i%2FKzDBu@x1n/
> [3] https://lore.kernel.org/all/d0eb0a13-16dc-1ac1-653a-78b7273781e3@collabora.com/
> [4] https://github.com/xzpeter/clibs/blob/master/uffd-test/uffd-wp-perf.c
> 
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>   Documentation/admin-guide/mm/userfaultfd.rst | 17 ++++++
>   fs/userfaultfd.c                             | 16 ++++++
>   include/linux/mm_inline.h                    |  6 +++
>   include/linux/userfaultfd_k.h                | 23 ++++++++
>   include/uapi/linux/userfaultfd.h             | 10 +++-
>   mm/memory.c                                  | 56 +++++++++++++++-----
>   mm/mprotect.c                                | 51 ++++++++++++++----
>   7 files changed, 154 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
> index 7dc823b56ca4..c86b56c95ea6 100644
> --- a/Documentation/admin-guide/mm/userfaultfd.rst
> +++ b/Documentation/admin-guide/mm/userfaultfd.rst
> @@ -219,6 +219,23 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
>   you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
>   used.
>   
> +Userfaultfd write-protect mode currently behave differently on none ptes
> +(when e.g. page is missing) over different types of memories.
> +
> +For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
> +(e.g. when pages are missing and not populated).  For file-backed memories
> +like shmem and hugetlbfs, none ptes will be write protected just like a
> +present pte.  In other words, there will be a userfaultfd write fault
> +message generated when writting to a missing page on file typed memories,

s/writting/writing/

> +as long as the page range was write-protected before.  Such a message will
> +not be generated on anonymous memories by default.
> +
> +If the application wants to be able to write protect none ptes on anonymous
> +memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
> +newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
> +and set the feature bit in advance to make sure none ptes will also be
> +write protected even upon anonymous memory.
> +

[...]

>   /*
>    * A number of key systems in x86 including ioremap() rely on the assumption
> @@ -1350,6 +1364,10 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
>   			      unsigned long addr, pte_t *pte,
>   			      struct zap_details *details, pte_t pteval)
>   {
> +	/* Zap on anonymous always means dropping everything */
> +	if (vma_is_anonymous(vma))
> +		return;
> +
>   	if (zap_drop_file_uffd_wp(details))
>   		return;
>   
> @@ -1456,8 +1474,12 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>   				continue;
>   			rss[mm_counter(page)]--;
>   		} else if (pte_marker_entry_uffd_wp(entry)) {
> -			/* Only drop the uffd-wp marker if explicitly requested */
> -			if (!zap_drop_file_uffd_wp(details))
> +			/*
> +			 * For anon: always drop the marker; for file: only
> +			 * drop the marker if explicitly requested.
> +			 */

So MADV_DONTNEED a pte marker in an anonymous VMA will always remove 
that marker. Is that the same handling as for MADV_DONTNEED on shmem or 
on fallocate(PUNCHHOLE) on shmem?

> +			if (!vma_is_anonymous(vma) &&
> +			    !zap_drop_file_uffd_wp(details))
>   				continue;

Maybe it would be nicer to have a zap_drop_uffd_wp_marker(vma, details) 
and have the comment in there. Especially because of the other hunk above.

So zap_drop_file_uffd_wp(details) -> zap_drop_uffd_wp_marker(vma, 
details) and move the anon handling + comment in there.


>   		} else if (is_hwpoison_entry(entry) ||
>   			   is_swapin_error_entry(entry)) {
> @@ -3624,6 +3646,14 @@ static vm_fault_t pte_marker_clear(struct vm_fault *vmf)
>   	return 0;
>   }
>   
> +static vm_fault_t do_pte_missing(struct vm_fault *vmf)
> +{
> +	if (vma_is_anonymous(vmf->vma))
> +		return do_anonymous_page(vmf);
> +	else
> +		return do_fault(vmf);

No need for the "else" statement.

> +}
> +
>   /*
>    * This is actually a page-missing access, but with uffd-wp special pte
>    * installed.  It means this pte was wr-protected before being unmapped.
> @@ -3634,11 +3664,10 @@ static vm_fault_t pte_marker_handle_uffd_wp(struct vm_fault *vmf)
>   	 * Just in case there're leftover special ptes even after the region
>   	 * got unregistered - we can simply clear them.
>   	 */
> -	if (unlikely(!userfaultfd_wp(vmf->vma) || vma_is_anonymous(vmf->vma)))
> +	if (unlikely(!userfaultfd_wp(vmf->vma)))
>   		return pte_marker_clear(vmf);
>   
> -	/* do_fault() can handle pte markers too like none pte */
> -	return do_fault(vmf);
> +	return do_pte_missing(vmf);
>   }
>   

[...]

> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 231929f119d9..455f7051098f 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -276,7 +276,15 @@ static long change_pte_range(struct mmu_gather *tlb,
>   		} else {
>   			/* It must be an none page, or what else?.. */
>   			WARN_ON_ONCE(!pte_none(oldpte));
> -			if (unlikely(uffd_wp && !vma_is_anonymous(vma))) {
> +
> +			/*
> +			 * Nobody plays with any none ptes besides
> +			 * userfaultfd when applying the protections.
> +			 */
> +			if (likely(!uffd_wp))
> +				continue;
> +
> +			if (userfaultfd_wp_use_markers(vma)) {
>   				/*
>   				 * For file-backed mem, we need to be able to
>   				 * wr-protect a none pte, because even if the
> @@ -320,23 +328,46 @@ static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd)
>   	return 0;
>   }
>   
> -/* Return true if we're uffd wr-protecting file-backed memory, or false */
> +/*
> + * Return true if we want to split huge thps in change protection

"huge thps" sounds redundant. "if we want to PTE-map a huge PMD" ?

> + * procedure, false otherwise.


In general,

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED
  2023-03-09 22:37 ` [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED Peter Xu
@ 2023-03-20 10:25   ` David Hildenbrand
  2023-03-20 14:43     ` Peter Xu
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2023-03-20 10:25 UTC (permalink / raw)
  To: Peter Xu, linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	Mike Rapoport, Andrea Arcangeli, Andrew Morton

On 09.03.23 23:37, Peter Xu wrote:
> Enable it by default on the stress test, and add some smoke tests for the
> pte markers on anonymous.

Would it make sense to make kernel support optional and test both paths 
-- once with the feature enabled (if available on the kernel we're 
testing) and once with the feature disabled?

-- 
Thanks,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED
  2023-03-20 10:21   ` David Hildenbrand
@ 2023-03-20 14:41     ` Peter Xu
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Xu @ 2023-03-20 14:41 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: linux-mm, linux-kernel, Nadav Amit, Axel Rasmussen, Paul Gofman,
	Muhammad Usama Anjum, Mike Rapoport, Andrea Arcangeli,
	Andrew Morton

On Mon, Mar 20, 2023 at 11:21:13AM +0100, David Hildenbrand wrote:
> 
> >    (1) With huge page disabled
> >    echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
> >    ./uffd_wp_perf
> >    Test DEFAULT: 4
> >    Test PRE-READ: 1111453 (pre-fault 1101011)
> >    Test MADVISE: 278276 (pre-fault 266378)
> 
> Thinking about it, I guess the biggest slowdown here is the "one fake
> pagefault at a time" handling.

I think so, though I assume the idea here is to avoid any faulting.

> 
> >    Test WP-UNPOPULATE: 11712
> > 
> >    (2) With Huge page enabled
> >    echo always > /sys/kernel/mm/transparent_hugepage/enabled
> >    ./uffd_wp_perf
> >    Test DEFAULT: 4
> >    Test PRE-READ: 22521 (pre-fault 22348)
> >    Test MADVISE: 4909 (pre-fault 4743)
> >    Test WP-UNPOPULATE: 14448
> > 
> > There'll be a great perf boost for no-thp case, while for thp enabled with
> > extreme case of all-thp-zero WP_UNPOPULATED can be slower than MADVISE, but
> > that's low possibility in reality, also the overhead was not reduced but
> > postponed until a follow up write on any huge zero thp, so potentially it
> > is faster by making the follow up writes slower.
> > 
> > [1] https://lore.kernel.org/all/20210401092226.102804-4-andrey.gruzdev@virtuozzo.com/
> > [2] https://lore.kernel.org/all/Y+v2HJ8+3i%2FKzDBu@x1n/
> > [3] https://lore.kernel.org/all/d0eb0a13-16dc-1ac1-653a-78b7273781e3@collabora.com/
> > [4] https://github.com/xzpeter/clibs/blob/master/uffd-test/uffd-wp-perf.c
> > 
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >   Documentation/admin-guide/mm/userfaultfd.rst | 17 ++++++
> >   fs/userfaultfd.c                             | 16 ++++++
> >   include/linux/mm_inline.h                    |  6 +++
> >   include/linux/userfaultfd_k.h                | 23 ++++++++
> >   include/uapi/linux/userfaultfd.h             | 10 +++-
> >   mm/memory.c                                  | 56 +++++++++++++++-----
> >   mm/mprotect.c                                | 51 ++++++++++++++----
> >   7 files changed, 154 insertions(+), 25 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
> > index 7dc823b56ca4..c86b56c95ea6 100644
> > --- a/Documentation/admin-guide/mm/userfaultfd.rst
> > +++ b/Documentation/admin-guide/mm/userfaultfd.rst
> > @@ -219,6 +219,23 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
> >   you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
> >   used.
> > +Userfaultfd write-protect mode currently behave differently on none ptes
> > +(when e.g. page is missing) over different types of memories.
> > +
> > +For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
> > +(e.g. when pages are missing and not populated).  For file-backed memories
> > +like shmem and hugetlbfs, none ptes will be write protected just like a
> > +present pte.  In other words, there will be a userfaultfd write fault
> > +message generated when writting to a missing page on file typed memories,
> 
> s/writting/writing/
> 
> > +as long as the page range was write-protected before.  Such a message will
> > +not be generated on anonymous memories by default.
> > +
> > +If the application wants to be able to write protect none ptes on anonymous
> > +memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
> > +newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
> > +and set the feature bit in advance to make sure none ptes will also be
> > +write protected even upon anonymous memory.
> > +
> 
> [...]
> 
> >   /*
> >    * A number of key systems in x86 including ioremap() rely on the assumption
> > @@ -1350,6 +1364,10 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
> >   			      unsigned long addr, pte_t *pte,
> >   			      struct zap_details *details, pte_t pteval)
> >   {
> > +	/* Zap on anonymous always means dropping everything */
> > +	if (vma_is_anonymous(vma))
> > +		return;
> > +
> >   	if (zap_drop_file_uffd_wp(details))
> >   		return;
> > @@ -1456,8 +1474,12 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
> >   				continue;
> >   			rss[mm_counter(page)]--;
> >   		} else if (pte_marker_entry_uffd_wp(entry)) {
> > -			/* Only drop the uffd-wp marker if explicitly requested */
> > -			if (!zap_drop_file_uffd_wp(details))
> > +			/*
> > +			 * For anon: always drop the marker; for file: only
> > +			 * drop the marker if explicitly requested.
> > +			 */
> 
> So MADV_DONTNEED a pte marker in an anonymous VMA will always remove that
> marker.

Yes.

> Is that the same handling as for MADV_DONTNEED on shmem or on
> fallocate(PUNCHHOLE) on shmem?

Same as PUNCHHOLE for shmem, while DONTNEED for shmem will retain the
marker.  Here the idea is we drop the marker if the user wants to drop the
page, no matter what type of memory is underneath.

> 
> > +			if (!vma_is_anonymous(vma) &&
> > +			    !zap_drop_file_uffd_wp(details))
> >   				continue;
> 
> Maybe it would be nicer to have a zap_drop_uffd_wp_marker(vma, details) and
> have the comment in there. Especially because of the other hunk above.
> 
> So zap_drop_file_uffd_wp(details) -> zap_drop_uffd_wp_marker(vma, details)
> and move the anon handling + comment in there.

Yes we can.

Actually here I always thought DROP_MARKER is too specific and the caller
will be confused on when to pass it in.

After introduction of ZAP_FLAG_UNMAP for hugetlb, I think we can also have
another more generic flag ZAP_FLAG_TRUNCATE only set during truncations,
then here the old DROP_MARKER can be replaced by "TRUNCATE | UNMAP".

> 
> 
> >   		} else if (is_hwpoison_entry(entry) ||
> >   			   is_swapin_error_entry(entry)) {
> > @@ -3624,6 +3646,14 @@ static vm_fault_t pte_marker_clear(struct vm_fault *vmf)
> >   	return 0;
> >   }
> > +static vm_fault_t do_pte_missing(struct vm_fault *vmf)
> > +{
> > +	if (vma_is_anonymous(vmf->vma))
> > +		return do_anonymous_page(vmf);
> > +	else
> > +		return do_fault(vmf);
> 
> No need for the "else" statement.

I don't see much difference in this specific context, but I'm fine to drop
it too.

> 
> > +}
> > +
> >   /*
> >    * This is actually a page-missing access, but with uffd-wp special pte
> >    * installed.  It means this pte was wr-protected before being unmapped.
> > @@ -3634,11 +3664,10 @@ static vm_fault_t pte_marker_handle_uffd_wp(struct vm_fault *vmf)
> >   	 * Just in case there're leftover special ptes even after the region
> >   	 * got unregistered - we can simply clear them.
> >   	 */
> > -	if (unlikely(!userfaultfd_wp(vmf->vma) || vma_is_anonymous(vmf->vma)))
> > +	if (unlikely(!userfaultfd_wp(vmf->vma)))
> >   		return pte_marker_clear(vmf);
> > -	/* do_fault() can handle pte markers too like none pte */
> > -	return do_fault(vmf);
> > +	return do_pte_missing(vmf);
> >   }
> 
> [...]
> 
> > diff --git a/mm/mprotect.c b/mm/mprotect.c
> > index 231929f119d9..455f7051098f 100644
> > --- a/mm/mprotect.c
> > +++ b/mm/mprotect.c
> > @@ -276,7 +276,15 @@ static long change_pte_range(struct mmu_gather *tlb,
> >   		} else {
> >   			/* It must be an none page, or what else?.. */
> >   			WARN_ON_ONCE(!pte_none(oldpte));
> > -			if (unlikely(uffd_wp && !vma_is_anonymous(vma))) {
> > +
> > +			/*
> > +			 * Nobody plays with any none ptes besides
> > +			 * userfaultfd when applying the protections.
> > +			 */
> > +			if (likely(!uffd_wp))
> > +				continue;
> > +
> > +			if (userfaultfd_wp_use_markers(vma)) {
> >   				/*
> >   				 * For file-backed mem, we need to be able to
> >   				 * wr-protect a none pte, because even if the
> > @@ -320,23 +328,46 @@ static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd)
> >   	return 0;
> >   }
> > -/* Return true if we're uffd wr-protecting file-backed memory, or false */
> > +/*
> > + * Return true if we want to split huge thps in change protection
> 
> "huge thps" sounds redundant. "if we want to PTE-map a huge PMD" ?

Sure.

> 
> > + * procedure, false otherwise.
> 
> 
> In general,
> 
> Acked-by: David Hildenbrand <david@redhat.com>

Thanks,

-- 
Peter Xu



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED
  2023-03-20 10:25   ` David Hildenbrand
@ 2023-03-20 14:43     ` Peter Xu
  2023-03-20 15:01       ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Xu @ 2023-03-20 14:43 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: linux-mm, linux-kernel, Nadav Amit, Axel Rasmussen, Paul Gofman,
	Muhammad Usama Anjum, Mike Rapoport, Andrea Arcangeli,
	Andrew Morton

On Mon, Mar 20, 2023 at 11:25:43AM +0100, David Hildenbrand wrote:
> On 09.03.23 23:37, Peter Xu wrote:
> > Enable it by default on the stress test, and add some smoke tests for the
> > pte markers on anonymous.
> 
> Would it make sense to make kernel support optional and test both paths --
> once with the feature enabled (if available on the kernel we're testing) and
> once with the feature disabled?

Yeah, I think the current uffd selftest is not friendly to old kernels so I
made it simple - IOW the test should fail already on old kernels AFAIK.
Maybe I can prepare some patches this week or next to cleanup some parts of
it.

Thanks,

-- 
Peter Xu



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED
  2023-03-20 14:43     ` Peter Xu
@ 2023-03-20 15:01       ` David Hildenbrand
  0 siblings, 0 replies; 9+ messages in thread
From: David Hildenbrand @ 2023-03-20 15:01 UTC (permalink / raw)
  To: Peter Xu
  Cc: linux-mm, linux-kernel, Nadav Amit, Axel Rasmussen, Paul Gofman,
	Muhammad Usama Anjum, Mike Rapoport, Andrea Arcangeli,
	Andrew Morton

On 20.03.23 15:43, Peter Xu wrote:
> On Mon, Mar 20, 2023 at 11:25:43AM +0100, David Hildenbrand wrote:
>> On 09.03.23 23:37, Peter Xu wrote:
>>> Enable it by default on the stress test, and add some smoke tests for the
>>> pte markers on anonymous.
>>
>> Would it make sense to make kernel support optional and test both paths --
>> once with the feature enabled (if available on the kernel we're testing) and
>> once with the feature disabled?
> 
> Yeah, I think the current uffd selftest is not friendly to old kernels so I
> made it simple - IOW the test should fail already on old kernels AFAIK.
> Maybe I can prepare some patches this week or next to cleanup some parts of
> it.

Some people to tend to run upstream selftests on older kernels, but I 
guess this is not high priority. Can always be added on top.

-- 
Thanks,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED
  2023-03-09 22:37 ` [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Peter Xu
  2023-03-20 10:21   ` David Hildenbrand
@ 2023-03-24 15:21   ` Peter Xu
  1 sibling, 0 replies; 9+ messages in thread
From: Peter Xu @ 2023-03-24 15:21 UTC (permalink / raw)
  To: linux-mm, linux-kernel
  Cc: Nadav Amit, Axel Rasmussen, Paul Gofman, Muhammad Usama Anjum,
	David Hildenbrand, Mike Rapoport, Andrea Arcangeli,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Thu, Mar 09, 2023 at 05:37:10PM -0500, Peter Xu wrote:
> This is a new feature that controls how uffd-wp handles none ptes.  When
> it's set, the kernel will handle anonymous memory the same way as file
> memory, by allowing the user to wr-protect unpopulated ptes.

[...]

Hi, Andrew,

Could you add a fixup to this patch as attached?  It contains two comment
changes suggested by David, and also a oneliner fix to khugepaged (to bail
out anon thp collapsing when seeing pte markers).  The latter one was
something I spot only later on.

Thanks,

-- 
Peter Xu

[-- Attachment #2: 0001-fixup-mm-uffd-UFFD_FEATURE_WP_UNPOPULATED.patch --]
[-- Type: text/plain, Size: 2291 bytes --]

From 085596bc8913349cbeb3ec3303815f71f1a34d89 Mon Sep 17 00:00:00 2001
From: Peter Xu <peterx@redhat.com>
Date: Tue, 21 Mar 2023 16:09:26 -0400
Subject: [PATCH] fixup! mm/uffd: UFFD_FEATURE_WP_UNPOPULATED

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 Documentation/admin-guide/mm/userfaultfd.rst | 2 +-
 mm/khugepaged.c                              | 2 +-
 mm/mprotect.c                                | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 16843d5a4f65..7c304e432205 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -226,7 +226,7 @@ For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
 (e.g. when pages are missing and not populated).  For file-backed memories
 like shmem and hugetlbfs, none ptes will be write protected just like a
 present pte.  In other words, there will be a userfaultfd write fault
-message generated when writting to a missing page on file typed memories,
+message generated when writing to a missing page on file typed memories,
 as long as the page range was write-protected before.  Such a message will
 not be generated on anonymous memories by default.
 
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index bdde0a02811b..2a5372c49b82 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1283,7 +1283,7 @@ static int hpage_collapse_scan_pmd(struct mm_struct *mm,
 				 * enabled swap entries.  Please see
 				 * comment below for pte_uffd_wp().
 				 */
-				if (pte_swp_uffd_wp(pteval)) {
+				if (pte_swp_uffd_wp_any(pteval)) {
 					result = SCAN_PTE_UFFD_WP;
 					goto out_unmap;
 				}
diff --git a/mm/mprotect.c b/mm/mprotect.c
index e27bbd0fde6f..b9da9a5f87fe 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -329,8 +329,8 @@ static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd)
 }
 
 /*
- * Return true if we want to split huge thps in change protection
- * procedure, false otherwise.
+ * Return true if we want to split THPs into PTE mappings in change
+ * protection procedure, false otherwise.
  */
 static inline bool
 pgtable_split_needed(struct vm_area_struct *vma, unsigned long cp_flags)
-- 
2.39.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-03-24 15:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-09 22:37 [PATCH v4 0/2] mm/uffd: Add feature bit UFFD_FEATURE_WP_UNPOPULATED Peter Xu
2023-03-09 22:37 ` [PATCH v4 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Peter Xu
2023-03-20 10:21   ` David Hildenbrand
2023-03-20 14:41     ` Peter Xu
2023-03-24 15:21   ` Peter Xu
2023-03-09 22:37 ` [PATCH v4 2/2] selftests/mm: Smoke test UFFD_FEATURE_WP_UNPOPULATED Peter Xu
2023-03-20 10:25   ` David Hildenbrand
2023-03-20 14:43     ` Peter Xu
2023-03-20 15:01       ` David Hildenbrand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).