Re: [PATCH v2 04/14] mm: add VM_UFFD_RWP VMA flag

From: Kiryl Shutsemau

Date: Fri May 22 2026 - 06:44:44 EST


On Tue, May 12, 2026 at 07:48:57PM +0300, Mike Rapoport wrote:
> On Fri, May 08, 2026 at 04:55:16PM +0100, Kiryl Shutsemau (Meta) wrote:
> > Preparatory patch for userfaultfd read-write protection (RWP). RWP
> > extends userfaultfd protection from plain write-protection (WP) to
> > full read-write protection: accesses to an RWP-protected range --
> > reads as well as writes -- trap through userfaultfd.
> >
> > RWP marks ranges by combining PAGE_NONE with the uffd PTE bit, so
> > the flag is only meaningful when both primitives exist. A new
> > CONFIG_USERFAULTFD_RWP Kconfig symbol auto-selects when CONFIG_64BIT,
> > CONFIG_ARCH_HAS_PTE_PROTNONE, and CONFIG_HAVE_ARCH_USERFAULTFD_WP
> > are all set; call sites that gate on the flag depend on the symbol.
> > Elsewhere VM_UFFD_RWP aliases VM_NONE and every downstream check
> > folds to dead code.
> >
> > Nothing sets the flag yet.
>
> And nothing check for it as well, am I right?

Yep.

> Worth noting here, IMHO.

Will do.

>
> > Signed-off-by: Kiryl Shutsemau <kas@xxxxxxxxxx>
> > Assisted-by: Claude:claude-opus-4-6
> > ---
> > Documentation/filesystems/proc.rst | 1 +
> > fs/proc/task_mmu.c | 3 +++
> > include/linux/mm.h | 28 +++++++++++++++++----------
> > include/linux/userfaultfd_k.h | 31 +++++++++++++++++++++++++-----
> > include/trace/events/mmflags.h | 7 +++++++
> > mm/Kconfig | 9 +++++++++
> > 6 files changed, 64 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> > index 98f546e83cd2..fcf308dba311 100644
> > --- a/include/linux/userfaultfd_k.h
> > +++ b/include/linux/userfaultfd_k.h
> > @@ -21,10 +21,11 @@
> > #include <linux/hugetlb_inline.h>
> >
> > /* The set of all possible UFFD-related VM flags. */
> > -#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_WP | VM_UFFD_MINOR)
> > +#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_WP | VM_UFFD_MINOR | \
> > + VM_UFFD_RWP)
>
> Nit: can we keep mode bits together and protection bits together here and
> in the below changes?

Yep, make sense.

> Otherwise looks good to me
>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>

Thanks!

--
Kiryl Shutsemau / Kirill A. Shutemov