Re: [PATCH 5/6] userfaultfd: decouple fault reason from VMA flags

On 8/27/26 09:49, Mike Rapoport wrote:

On Mon, Aug 24, 2026 at 04:46:14PM +0200, David Hildenbrand (Arm) wrote:

quoted

On 8/23/26 14:17, Mike Rapoport (Microsoft) wrote:

quoted

Introduce enum uffd_reason to define reasons for user faults rather than
overload VM_UFFD_* VMA flags for that.

Using a dedicated enum makes the code clearer and decoupling the fault
reason from VMA flags clears the way for moving the uffd mode bits out
of VMA namespace.

No functional change.

Assisted-by: copilot:claude-opus-4.6
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 include/linux/userfaultfd_k.h    | 16 ++++++++++++++--
 include/uapi/linux/userfaultfd.h |  6 +++---
 mm/huge_memory.c                 |  6 +++---
 mm/hugetlb.c                     | 10 +++++-----
 mm/memory.c                      | 10 +++++-----
 mm/shmem.c                       |  4 ++--
 mm/userfaultfd.c                 | 30 +++++++++++++++---------------
 7 files changed, 47 insertions(+), 35 deletions(-)

diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
index 45355bdb4ec7..f401623f315d 100644
--- a/include/linux/userfaultfd_k.h
+++ b/include/linux/userfaultfd_k.h

@@ -9,6 +9,18 @@
 #ifndef _LINUX_USERFAULTFD_K_H
 #define _LINUX_USERFAULTFD_K_H
 
+#include <linux/bits.h>
+
+/* Fault reason #PF handler passes to handle_userfault() */
+enum uf_reason {

Can we just call this "userfault_reason" or "uffd_reason" ? Maybe the latter is
actually what we want?

userfault_reason sounds better to me.

It describes what kind of user fault we are handling and the 'fd' part has
nothing to do with it. 
We do use uffd as a short name for the subsystem, but still most if not all
userfaultfd "external" APIs use userfault_ prefix.

uf_ was an attempt to make it wee shorter :)

Yeah, I got that; while uffd is a known acronym, the uf_ not so much (and also I
wouldn't suggest it to become a thing, lol :) )

I've been wondering for a while whether it really should be called

	handle_userfault()

And not instead

	handle_userfaultfd()

Or maybe even better

	handle_uffd_fault()

And then have

	uffd_fault_reason

... but just a thought.

-- 
Cheers,

David