From: Dev Jain <dev.jain@arm.com>
To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org
Cc: Dev Jain <dev.jain@arm.com>,
kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev,
baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com,
weixugc@google.com, liam@infradead.org, vbabka@kernel.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
riel@surriel.com, harry@kernel.org, jannh@google.com,
lance.yang@linux.dev, ryan.roberts@arm.com,
anshuman.khandual@arm.com
Subject: [PATCH v2 1/3] mm/memory: move pte_install_uffd_wp_if_needed() into memory.c
Date: Mon, 20 Jul 2026 06:55:05 +0000 [thread overview]
Message-ID: <20260720065508.2695106-2-dev.jain@arm.com> (raw)
In-Reply-To: <20260720065508.2695106-1-dev.jain@arm.com>
pte_install_uffd_wp_if_needed() has grown too large for mm_inline.h.
Move it to memory.c.
This helper is only used inside mm/, so declare it in mm/internal.h
instead of a public header.
While at it, convert the comment to kerneldoc and rename the local
arguments from pte/pteval to ptep/pte so the pointer and PTE value are
easier to distinguish.
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
include/linux/mm_inline.h | 53 ----------------------------------
mm/internal.h | 3 ++
mm/memory.c | 60 +++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 53 deletions(-)
diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
index b5c4dc0f3fe32..621c8653d8f7e 100644
--- a/include/linux/mm_inline.h
+++ b/include/linux/mm_inline.h
@@ -566,59 +566,6 @@ static inline pte_marker copy_pte_marker(
return dstm;
}
-/*
- * If this pte is wr-protected by uffd-wp in any form, arm the special pte to
- * replace a none pte. NOTE! This should only be called when *pte is already
- * cleared so we will never accidentally replace something valuable. Meanwhile
- * none pte also means we are not demoting the pte so tlb flushed is not needed.
- * E.g., when pte cleared the caller should have taken care of the tlb flush.
- *
- * Must be called with pgtable lock held so that no thread will see the none
- * pte, and if they see it, they'll fault and serialize at the pgtable lock.
- *
- * Returns true if an uffd-wp pte was installed, false otherwise.
- */
-static inline bool
-pte_install_uffd_wp_if_needed(struct vm_area_struct *vma, unsigned long addr,
- pte_t *pte, pte_t pteval)
-{
- bool arm_uffd_pte = false;
-
- if (!uffd_supports_wp_marker())
- return false;
-
- /* The current status of the pte should be "cleared" before calling */
- WARN_ON_ONCE(!pte_none(ptep_get(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 false;
-
- /* A uffd-wp wr-protected normal pte */
- if (unlikely(pte_present(pteval) && pte_uffd(pteval)))
- arm_uffd_pte = true;
-
- /*
- * A uffd-wp wr-protected swap pte. Note: this should even cover an
- * existing pte marker with uffd-wp bit set.
- */
- if (unlikely(pte_swp_uffd_any(pteval)))
- arm_uffd_pte = true;
-
- if (unlikely(arm_uffd_pte)) {
- set_pte_at(vma->vm_mm, addr, pte,
- make_pte_marker(PTE_MARKER_UFFD_WP));
- return true;
- }
-
- return false;
-}
-
static inline bool vma_has_recency(const struct vm_area_struct *vma)
{
if (vma->vm_flags & (VM_SEQ_READ | VM_RAND_READ))
diff --git a/mm/internal.h b/mm/internal.h
index f26423de4ca28..b6a3589a61c1a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -276,6 +276,9 @@ void unmap_vmas(struct mmu_gather *tlb, struct unmap_desc *unmap);
#ifdef CONFIG_MMU
+bool pte_install_uffd_wp_if_needed(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep, pte_t pte);
+
static inline void get_anon_vma(struct anon_vma *anon_vma)
{
atomic_inc(&anon_vma->refcount);
diff --git a/mm/memory.c b/mm/memory.c
index d5e87624f6920..6c0c4c774674a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1675,6 +1675,66 @@ static inline bool zap_drop_markers(struct zap_details *details)
return details->zap_flags & ZAP_FLAG_DROP_MARKER;
}
+/**
+ * pte_install_uffd_wp_if_needed - install uffd-wp marker after clearing a PTE
+ * @vma: The VMA the page is mapped into.
+ * @addr: Address the page is mapped at.
+ * @ptep: Page table pointer for this entry.
+ * @pte: Old value of the entry pointed to by @ptep.
+ *
+ * If the PTE was write-protected by uffd-wp in any form, arm a special PTE
+ * to replace a none PTE. NOTE! This should only be called when the PTE is
+ * already cleared so we will never accidentally replace something valuable.
+ * Meanwhile none PTEs also mean we are not demoting the PTE so a TLB flush is
+ * not needed. E.g., when the PTE was cleared, the caller should have taken care
+ * of the TLB flush.
+ *
+ * Must be called with the page table lock held so that no thread will see the
+ * none PTE, and if they see it, they'll fault and serialize at the page table
+ * lock.
+ *
+ * Returns true if an uffd-wp PTE was installed, false otherwise.
+ */
+bool pte_install_uffd_wp_if_needed(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep, pte_t pte)
+{
+ bool arm_uffd_pte = false;
+
+ if (!uffd_supports_wp_marker())
+ return false;
+
+ /* The current status of the pte should be "cleared" before calling */
+ WARN_ON_ONCE(!pte_none(ptep_get(ptep)));
+
+ /*
+ * 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 false;
+
+ /* A uffd-wp wr-protected normal pte */
+ if (unlikely(pte_present(pte) && pte_uffd(pte)))
+ arm_uffd_pte = true;
+
+ /*
+ * A uffd-wp wr-protected swap pte. Note: this should even cover an
+ * existing pte marker with uffd-wp bit set.
+ */
+ if (unlikely(pte_swp_uffd_any(pte)))
+ arm_uffd_pte = true;
+
+ if (unlikely(arm_uffd_pte)) {
+ set_pte_at(vma->vm_mm, addr, ptep,
+ make_pte_marker(PTE_MARKER_UFFD_WP));
+ return true;
+ }
+
+ return false;
+}
+
/*
* This function makes sure that we'll replace the none pte with an uffd-wp
* swap special pte marker when necessary. Must be with the pgtable lock held.
--
2.43.0
next prev parent reply other threads:[~2026-07-20 6:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 6:55 [PATCH v2 0/3] Batch unmap of uffd-wp file folios Dev Jain
2026-07-20 6:55 ` Dev Jain [this message]
2026-07-20 8:19 ` [PATCH v2 1/3] mm/memory: move pte_install_uffd_wp_if_needed() into memory.c David Hildenbrand (Arm)
2026-07-20 6:55 ` [PATCH v2 2/3] mm/memory: batch set uffd-wp markers during zapping Dev Jain
2026-07-20 8:20 ` David Hildenbrand (Arm)
2026-07-20 6:55 ` [PATCH v2 3/3] mm/rmap: batch unmap file folios belonging to uffd-wp VMAs Dev Jain
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=20260720065508.2695106-2-dev.jain@arm.com \
--to=dev.jain@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=kasong@tencent.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=qi.zheng@linux.dev \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.