Re: [PATCH v3 1/4] mm: Introduce vm_uffd_ops API
From: David Hildenbrand
Date: Wed Oct 01 2025 - 10:40:11 EST
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.
I think it can be done with a handful of LOC and avoid having to use VM_
flags in this API.
--
Cheers
David / dhildenb