All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Barry Song <baohua@kernel.org>, Dev Jain <dev.jain@arm.com>,
	Hugh Dickins <hughd@google.com>, Jann Horn <jannh@google.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	John Hubbard <jhubbard@nvidia.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Lance Yang <lance.yang@linux.dev>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Michal Hocko <mhocko@suse.com>,
	Muchun Song <muchun.song@linux.dev>,
	Nico Pache <nico.pache@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Pedro Falcato <pfalcato@suse.de>, Peter Xu <peterx@redhat.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Usama Arif <usama.arif@linux.dev>,
	Vlastimil Babka <vbabka@kernel.org>, Zi Yan <ziy@nvidia.com>,
	linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] userfaultfd: decouple fault reason from VMA flags
Date: Thu, 27 Aug 2026 12:09:13 +0300	[thread overview]
Message-ID: <ao_-uZrrsVX9lzbz@kernel.org> (raw)
In-Reply-To: <e8aaddde-0a07-4197-9874-5ca0ea8af43f@kernel.org>

On Thu, Aug 27, 2026 at 10:10:24AM +0200, David Hildenbrand (Arm) wrote:
> On 8/27/26 09:49, Mike Rapoport wrote:
> > On Mon, Aug 24, 2026 at 04:46:14PM +0200, David Hildenbrand (Arm) wrote:
> >> On 8/23/26 14:17, Mike Rapoport (Microsoft) wrote:
> >>> 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()

The 'fd' part here sounds really weird :)
 
> Or maybe even better
> 
> 	handle_uffd_fault()

That's somehow tautological, but maybe using uffd_ as prefix would make it
a "subsystem namespace", so tautology won't be as blunt:

	uffd_handle_fault()
 
> And then have
> 
> 	uffd_fault_reason

Could work, yes. No strong feelings between this one and userfault_reason.
 
> ... but just a thought.
> 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2026-08-27  9:09 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-23 12:17 [PATCH 0/6] userfaultfd: decouple uffd mode from VMA flags Mike Rapoport (Microsoft)
2026-08-23 12:17 ` [PATCH 1/6] mm/gup: move gup_can_follow_protnone() to gup.c Mike Rapoport (Microsoft)
2026-08-23 21:03   ` Barry Song
2026-08-24 14:42   ` David Hildenbrand (Arm)
2026-08-25 10:10     ` Mike Rapoport
2026-08-24 14:59   ` Lorenzo Stoakes (ARM)
2026-08-25  2:03   ` Zi Yan
2026-08-23 12:17 ` [PATCH 2/6] userfaultfd: constify VMA parameter of userfaultfd_*() helpers Mike Rapoport (Microsoft)
2026-08-23 12:27   ` sashiko-bot
2026-08-23 21:03   ` Barry Song
2026-08-24 15:03   ` Lorenzo Stoakes (ARM)
2026-08-25  2:03   ` Zi Yan
2026-08-23 12:17 ` [PATCH 3/6] userfaultfd: use userfaultfd_*() helpers instead of open coded flag tests Mike Rapoport (Microsoft)
2026-08-23 21:14   ` Barry Song
2026-08-24 15:10   ` Lorenzo Stoakes (ARM)
2026-08-25 11:19     ` Mike Rapoport
2026-08-25 11:26       ` Lorenzo Stoakes (ARM)
2026-08-27  7:14         ` Mike Rapoport
2026-08-23 12:17 ` [PATCH 4/6] userfaultfd: rename vm_userfaultfd_ctx to vm_uffd_state Mike Rapoport (Microsoft)
2026-08-24 14:43   ` David Hildenbrand (Arm)
2026-08-24 15:42   ` Lorenzo Stoakes (ARM)
2026-08-23 12:17 ` [PATCH 5/6] userfaultfd: decouple fault reason from VMA flags Mike Rapoport (Microsoft)
2026-08-24  8:12   ` Muchun Song
2026-08-24 14:46   ` David Hildenbrand (Arm)
2026-08-27  7:49     ` Mike Rapoport
2026-08-27  8:10       ` David Hildenbrand (Arm)
2026-08-27  9:09         ` Mike Rapoport [this message]
2026-08-27  9:19           ` David Hildenbrand (Arm)
2026-08-27  9:21             ` Lorenzo Stoakes (ARM)
2026-08-24 16:28   ` Lorenzo Stoakes (ARM)
2026-08-25 10:37     ` Mike Rapoport
2026-08-25 11:08       ` David Hildenbrand (Arm)
2026-08-25 11:38         ` Lorenzo Stoakes (ARM)
2026-08-25 13:00       ` Lorenzo Stoakes (ARM)
2026-08-27  7:42         ` Mike Rapoport
2026-08-27 11:29           ` Lorenzo Stoakes (ARM)
2026-08-23 12:17 ` [PATCH 6/6] userfaultfd: collapse VM_UFFD_{MISSING,WP,MINOR,RWP} into single VM_UFFD Mike Rapoport (Microsoft)
2026-08-24  7:11   ` Lance Yang
2026-08-24  8:17     ` Mike Rapoport
2026-08-24  8:27       ` Lance Yang
2026-08-25 12:44   ` Lorenzo Stoakes (ARM)
2026-08-25 12:45     ` Lorenzo Stoakes (ARM)
2026-08-27  9:03     ` Mike Rapoport
2026-08-27 11:16       ` Lorenzo Stoakes (ARM)
2026-08-27 11:18         ` Lorenzo Stoakes (ARM)
2026-08-27 15:19           ` David Hildenbrand (Arm)
2026-08-29 11:00             ` Mike Rapoport
2026-08-29 18:42               ` Tal Zussman
2026-08-30  5:36                 ` Mike Rapoport

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=ao_-uZrrsVX9lzbz@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nico.pache@linux.dev \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --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.