From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Tal Zussman <tz2294@columbia.edu>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Mike Rapoport" <rppt@kernel.org>, "Peter Xu" <peterx@redhat.com>,
"James Houghton" <jthoughton@google.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Balbir Singh" <balbirs@nvidia.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Jann Horn" <jannh@google.com>,
"Pedro Falcato" <pfalcato@suse.de>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
"Andrei Vagin" <avagin@gmail.com>,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"Arnd Bergmann" <arnd@arndb.de>,
"Muhammad Usama Anjum" <usama.anjum@arm.com>,
"David Hildenbrand" <david@kernel.org>, "Zi Yan" <ziy@nvidia.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Byungchul Park" <byungchul@sk.com>,
"Gregory Price" <gourry@gourry.net>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>, "Barry Song" <baohua@kernel.org>,
"Lance Yang" <lance.yang@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>,
"Kiryl Shutsemau" <kas@kernel.org>,
"Chris Down" <chris@chrisdown.name>,
"Muchun Song" <muchun.song@linux.dev>,
"Oscar Salvador" <osalvador@suse.de>,
"Mikołaj Lenczewski" <miko.lenczewski@arm.com>,
"Michal Hocko" <mhocko@suse.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 10/12] mm: set the uffd-wp bit on a guard marker when write-protecting
Date: Thu, 12 Nov 2026 11:43:03 +0000 [thread overview]
Message-ID: <avWhaJzGbuIM-Bh-@gremlin> (raw)
In-Reply-To: <20261111-uffd-state-fixes-v1-10-00713d368976@columbia.edu>
On Wed, Nov 11, 2026 at 12:55:18PM -0500, Tal Zussman wrote:
> UFFDIO_WRITEPROTECT and PAGEMAP_SCAN with PM_SCAN_WP_MATCHING do not
> write-protect an entry that holds a guard marker. change_softleaf_pte()
> ignores guard markers, and make_uffd_wp_pte() only sets the swap uffd
> bit on the marker PTE, which guard removal clears along with the marker.
There's no 'swap uffd' bit, softleaf uffd bit :) (I need to rename some stuff
still...)
>
> On a file-backed VMA, the page is still in the page cache once the guard
> is removed. It faults back in writable, and writes to it are not
> reported.
>
> To fix it, set the uffd-wp bit on a guard marker of a file-backed VMA in
> both paths. A guard marker can carry that bit, and guard removal then
> keeps the write protection by leaving a uffd-wp marker in its place.
>
> Move is_guard_pte_marker() to leafops.h as pte_is_guard_marker(), next
> to pte_is_uffd_wp_marker(), so that make_uffd_wp_pte() can use it.
>
> A page that is write-protected while a guard is in place is now still
> write-protected after the guard is removed.
>
> Anonymous memory is left as it is. With UFFD_FEATURE_WP_UNPOPULATED, an
> entry that is write-protected while a guard is in place is still
> unprotected after the guard is removed.
>
> Fixes: f807123d578d ("mm: allow guard regions in file-backed and read-only mappings")
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
Similarly, please drop this patch.
This does leave the opposite order (guard region _then_ uffd register etc.)
unaddressed, but guard regions behave as if the range were unmapped, and
uffd-wp state does not survive an unmap/remap either, so I think it's
reasonable for WP not to propagate there.
> ---
> fs/proc/task_mmu.c | 7 +++++++
> include/linux/leafops.h | 14 ++++++++++++++
> mm/madvise.c | 11 ++---------
> mm/mprotect.c | 5 ++++-
> 4 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 752f1b13d47a..7b1c843a4fd0 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -2439,6 +2439,13 @@ static void make_uffd_wp_pte(struct vm_area_struct *vma,
> } else if (pte_none(ptent)) {
> set_pte_at(vma->vm_mm, addr, pte,
> make_pte_marker(PTE_MARKER_UFFD_WP));
> + } else if (!vma_is_anonymous(vma) && pte_is_guard_marker(ptent)) {
> + /* Keep the protection in the marker, as mprotect does. */
> + const softleaf_t entry = softleaf_from_pte(ptent);
> +
> + set_pte_at(vma->vm_mm, addr, pte,
> + make_pte_marker(softleaf_to_marker(entry) |
> + PTE_MARKER_UFFD_WP));
> } else {
> ptent = set_uffd_wp_swp_pte(ptent);
> set_pte_at(vma->vm_mm, addr, pte, ptent);
> diff --git a/include/linux/leafops.h b/include/linux/leafops.h
> index add4968ded44..831b85a184c4 100644
> --- a/include/linux/leafops.h
> +++ b/include/linux/leafops.h
> @@ -547,6 +547,20 @@ static inline bool pte_is_marker(pte_t pte)
> return softleaf_is_marker(softleaf_from_pte(pte));
> }
>
> +/**
> + * pte_is_guard_marker() - Does this PTE entry encode a guard region marker
> + * leaf entry?
> + * @pte: PTE entry.
> + *
> + * Returns: true if this PTE is a guard marker leaf entry, otherwise false.
> + */
> +static inline bool pte_is_guard_marker(pte_t pte)
> +{
> + const softleaf_t entry = softleaf_from_pte(pte);
> +
> + return softleaf_is_guard_marker(entry);
> +}
> +
> /**
> * pte_is_uffd_wp_marker() - Does this PTE entry encode a userfaultfd write
> * protect marker leaf entry?
> diff --git a/mm/madvise.c b/mm/madvise.c
> index e2c6b0f26672..e8b05dc899f1 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -1085,13 +1085,6 @@ static bool is_valid_guard_vma(const struct vm_area_struct *vma,
> return true;
> }
>
> -static bool is_guard_pte_marker(pte_t ptent)
> -{
> - const softleaf_t entry = softleaf_from_pte(ptent);
> -
> - return softleaf_is_guard_marker(entry);
> -}
> -
> static int guard_install_pud_entry(pud_t *pud, unsigned long addr,
> unsigned long next, struct mm_walk *walk)
> {
> @@ -1117,7 +1110,7 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
> unsigned long *nr_pages = (unsigned long *)walk->private;
>
> /* If there is already a guard page marker, we have nothing to do. */
> - if (is_guard_pte_marker(pteval)) {
> + if (pte_is_guard_marker(pteval)) {
> (*nr_pages)++;
>
> return 0;
> @@ -1275,7 +1268,7 @@ static int guard_remove_pte_entry(pte_t *pte, unsigned long addr,
> {
> pte_t ptent = ptep_get(pte);
>
> - if (is_guard_pte_marker(ptent)) {
> + if (pte_is_guard_marker(ptent)) {
> const softleaf_t entry = softleaf_from_pte(ptent);
> const pte_marker marker = softleaf_to_marker(entry) &
> ~PTE_MARKER_GUARD;
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 6cc5b99b4185..3f2d6e3aca93 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -261,7 +261,10 @@ static long change_softleaf_pte(struct vm_area_struct *vma,
> const pte_marker old = softleaf_to_marker(entry);
> pte_marker marker = old;
>
> - if (uffd_prot_resolve)
> + if ((cp_flags & MM_CP_UFFD_WP) &&
> + !vma_is_anonymous(vma))
> + marker |= PTE_MARKER_UFFD_WP;
> + else if (uffd_prot_resolve)
> marker &= ~PTE_MARKER_UFFD_WP;
>
> if (marker == old)
>
> --
> 2.39.5
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-11-12 11:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 17:55 [PATCH 00/12] userfaultfd: assorted fixes (part 1) Tal Zussman
2026-11-11 17:55 ` [PATCH 01/12] userfaultfd: use anonymous memory for UFFDIO_ZEROPAGE on private file mappings Tal Zussman
2026-11-12 18:05 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 02/12] userfaultfd: refuse UFFDIO_MOVE into a non-present huge destination PMD Tal Zussman
2026-11-12 17:56 ` sashiko-bot
2026-11-12 18:07 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 03/12] fs/proc/task_mmu: downgrade writable migration entries in PAGEMAP_SCAN write-protect Tal Zussman
2026-11-12 18:34 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 04/12] mm/migrate: keep the uffd bit when restoring a writable migration entry Tal Zussman
2026-11-12 18:44 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 05/12] fs/proc/task_mmu: write-protect device-private THPs in PAGEMAP_SCAN Tal Zussman
2026-11-12 19:34 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 06/12] mm/huge_memory: build the moved huge zero PMD from the destination VMA Tal Zussman
2026-11-11 19:12 ` Kiryl Shutsemau
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 07/12] mm/mremap: resolve uffd state when the context is dropped, not during the move Tal Zussman
2026-11-11 19:20 ` Kiryl Shutsemau
2026-11-11 22:39 ` Tal Zussman
2026-11-12 11:44 ` Lorenzo Stoakes (ARM)
2026-11-12 16:00 ` Tal Zussman
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 08/12] mm/migrate_device: do not migrate a uffd-protected zero page Tal Zussman
2026-11-11 17:55 ` [PATCH 09/12] mm/madvise: let a guard marker carry the uffd-wp bit Tal Zussman
2026-11-12 11:21 ` Lorenzo Stoakes (ARM)
2026-11-12 16:06 ` Tal Zussman
2026-11-11 17:55 ` [PATCH 10/12] mm: set the uffd-wp bit on a guard marker when write-protecting Tal Zussman
2026-11-12 11:43 ` Lorenzo Stoakes (ARM) [this message]
2026-11-11 17:55 ` [PATCH 11/12] mm/madvise: send UFFD_EVENT_REMOVE when installing guard regions Tal Zussman
2026-11-11 19:25 ` Kiryl Shutsemau
2026-11-11 23:21 ` Tal Zussman
2026-11-12 9:40 ` Jose A. Perez de Azpillaga
2026-11-12 11:57 ` Kiryl Shutsemau
2026-11-12 11:03 ` Lorenzo Stoakes (ARM)
2026-11-12 11:06 ` Lorenzo Stoakes (ARM)
2026-11-12 15:56 ` Tal Zussman
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 12/12] mm/userfaultfd: check hugetlb end alignment in UFFDIO_UNREGISTER pre-scan Tal Zussman
2026-11-12 19:52 ` Lorenzo Stoakes (ARM)
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=avWhaJzGbuIM-Bh-@gremlin \
--to=ljs@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=avagin@gmail.com \
--cc=balbirs@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=chris@chrisdown.name \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=jthoughton@google.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=miko.lenczewski@arm.com \
--cc=mirq-linux@rere.qmqm.pl \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sfr@canb.auug.org.au \
--cc=surenb@google.com \
--cc=tz2294@columbia.edu \
--cc=usama.anjum@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.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.