Re: [PATCH v3 1/4] mm: Introduce vm_uffd_ops API

[Peter Xu <peterx@redhat.com>]

On Wed, Oct 01, 2025 at 04:39:50PM +0200, David Hildenbrand wrote:
> On 01.10.25 16:35, Peter Xu wrote:
> > On Wed, Oct 01, 2025 at 03:58:14PM +0200, David Hildenbrand wrote:
> > > > > > > I briefly wondered whether we could use actual UFFD_FEATURE_* here, but they
> > > > > > > are rather unsuited for this case here (e.g., different feature flags for
> > > > > > > hugetlb support/shmem support etc).
> > > > > > > 
> > > > > > > But reading "uffd_ioctls" below, can't we derive the suitable vma flags from
> > > > > > > the supported ioctls?
> > > > > > > 
> > > > > > > _UFFDIO_COPY | _UFDIO_ZEROPAGE -> VM_UFFD_MISSING
> > > > > > > _UFFDIO_WRITEPROTECT -> VM_UFFD_WP
> > > > > > > _UFFDIO_CONTINUE -> VM_UFFD_MINOR
> > > > > > 
> > > > > > Yes we can deduce that, but it'll be unclear then when one stares at a
> > > > > > bunch of ioctls and cannot easily digest the modes the memory type
> > > > > > supports.  Here, the modes should be the most straightforward way to
> > > > > > describe the capability of a memory type.
> > > > > 
> > > > > I rather dislike the current split approach between vm-flags and ioctls.
> > > > > 
> > > > > I briefly thought about abstracting it for internal purposes further and
> > > > > just have some internal backend ("memory type") flags.
> > > > > 
> > > > > UFFD_BACKEND_FEAT_MISSING -> _UFFDIO_COPY and VM_UFFD_MISSING
> > > > > UFFD_BACKEND_FEAT_ZEROPAGE -> _UFDIO_ZEROPAGE
> > > > > UFFD_BACKEND_FEAT_WP -> _UFFDIO_WRITEPROTECT and VM_UFFD_WP
> > > > > UFFD_BACKEND_FEAT_MINOR -> _UFFDIO_CONTINUE and VM_UFFD_MINOR
> > > > > UFFD_BACKEND_FEAT_POISON -> _UFFDIO_POISON
> > > > 
> > > > This layer of mapping can be helpful to some, but maybe confusing to
> > > > others.. who is familiar with existing userfaultfd definitions.
> > > > 
> > > 
> > > Just wondering, is this confusing to you, and if so, which part?
> > > 
> > > To me it makes perfect sense and cleans up this API and not have to sets of
> > > flags that are somehow interlinked.
> > 
> > It adds the extra layer of mapping that will only be used in vm_uffd_ops
> > and the helper that will consume it.
> 
> Agreed, while making the API cleaner. I don't easily see what's confusing
> about that, though.

It will introduce another set of userfaultfd features, making it hard to
say what is the difference between the new set and UFFD_FEATURE_*.

> 
> I think it can be done with a handful of LOC and avoid having to use VM_
> flags in this API.

I waited for a few days, unfortunately we didn't get a second opinion.

David, do you feel OK I repost with the rest comments (almost renames), and
if we want yet another new set of features for userfaultfd, we work it on
top?  It'll be a trivial one patch to do the mappings if we want.  The
current patch is also the minimum changeset we need to unblock guest-memfd
minor fault.

Thanks,

-- 
Peter Xu