include/linux/mm.h | 9 +++ include/linux/userfaultfd_k.h | 83 ++++++++++++++++----------- mm/hugetlb.c | 19 +++++++ mm/shmem.c | 25 +++++++++ mm/userfaultfd.c | 102 ++++++++++++++++++++++++++-------- 5 files changed, 181 insertions(+), 57 deletions(-)
[based on latest akpm/mm-new of Sep 26th, commit e612c80ae0aeb]
v3 changelog:
- Fixed checkpatch issues on spaces or typedef
- Dropped uffd_copy() API
- Refined commit messages here and there to reflect the removal of uffd_copy()
v1: https://lore.kernel.org/r/20250620190342.1780170-1-peterx@redhat.com
v2: https://lore.kernel.org/r/20250627154655.2085903-1-peterx@redhat.com
This series is an alternative proposal of what Nikita proposed here on the
initial three patches:
https://lore.kernel.org/r/20250404154352.23078-1-kalyazin@amazon.com
This is not yet relevant to any guest-memfd support, but paving way for it.
Here, the major goal is to make kernel modules be able to opt-in with any
form of userfaultfd supports, like guest-memfd. This alternative option
should hopefully be cleaner, and avoid leaking userfault details into
vm_ops.fault().
It also means this series does not depend on anything. It's a pure
refactoring of userfaultfd internals to provide a generic API, so that
other types of files, especially RAM based, can support userfaultfd without
touching mm/ at all.
To achieve it, this series introduced a file operation called vm_uffd_ops.
The ops needs to be provided when a file type supports any of userfaultfd.
With that, I moved both hugetlbfs and shmem over, whenever possible. So
far due to concerns on exposing an uffd_copy() API, the MISSING faults are
still separately processed and can only be done within mm/. Hugetlbfs kept
its special paths untouched.
An example of shmem uffd_ops:
static const vm_uffd_ops shmem_uffd_ops = {
.uffd_features = __VM_UFFD_FLAGS,
.uffd_ioctls = BIT(_UFFDIO_COPY) |
BIT(_UFFDIO_ZEROPAGE) |
BIT(_UFFDIO_WRITEPROTECT) |
BIT(_UFFDIO_CONTINUE) |
BIT(_UFFDIO_POISON),
.uffd_get_folio = shmem_uffd_get_folio,
};
No functional change expected at all after the whole series applied. There
might be some slightly stricter check on uffd ops here and there in the
last patch, but that really shouldn't stand out anywhere to anyone.
For testing: besides the cross-compilation tests, I did also try with
uffd-stress in a VM to measure any perf difference before/after the change;
The static call becomes a pointer now. I really cannot measure anything
different, which is more or less expected.
Comments welcomed, thanks.
Peter Xu (4):
mm: Introduce vm_uffd_ops API
mm/shmem: Support vm_uffd_ops API
mm/hugetlb: Support vm_uffd_ops API
mm: Apply vm_uffd_ops API to core mm
include/linux/mm.h | 9 +++
include/linux/userfaultfd_k.h | 83 ++++++++++++++++-----------
mm/hugetlb.c | 19 +++++++
mm/shmem.c | 25 +++++++++
mm/userfaultfd.c | 102 ++++++++++++++++++++++++++--------
5 files changed, 181 insertions(+), 57 deletions(-)
--
2.50.1
* Peter Xu <peterx@redhat.com> [250926 17:17]:
> [based on latest akpm/mm-new of Sep 26th, commit e612c80ae0aeb]
>
> v3 changelog:
> - Fixed checkpatch issues on spaces or typedef
> - Dropped uffd_copy() API
> - Refined commit messages here and there to reflect the removal of uffd_copy()
>
> v1: https://lore.kernel.org/r/20250620190342.1780170-1-peterx@redhat.com
> v2: https://lore.kernel.org/r/20250627154655.2085903-1-peterx@redhat.com
>
> This series is an alternative proposal of what Nikita proposed here on the
> initial three patches:
>
> https://lore.kernel.org/r/20250404154352.23078-1-kalyazin@amazon.com
>
> This is not yet relevant to any guest-memfd support, but paving way for it.
It would be much easier to review this with the guest-memfd support in
this patch set. Any chance of including the target user?
> Here, the major goal is to make kernel modules be able to opt-in with any
> form of userfaultfd supports, like guest-memfd. This alternative option
> should hopefully be cleaner, and avoid leaking userfault details into
> vm_ops.fault().
>
> It also means this series does not depend on anything. It's a pure
> refactoring of userfaultfd internals to provide a generic API, so that
> other types of files, especially RAM based, can support userfaultfd without
> touching mm/ at all.
>
> To achieve it, this series introduced a file operation called vm_uffd_ops.
> The ops needs to be provided when a file type supports any of userfaultfd.
>
> With that, I moved both hugetlbfs and shmem over, whenever possible. So
> far due to concerns on exposing an uffd_copy() API, the MISSING faults are
> still separately processed and can only be done within mm/. Hugetlbfs kept
> its special paths untouched.
>
> An example of shmem uffd_ops:
>
> static const vm_uffd_ops shmem_uffd_ops = {
> .uffd_features = __VM_UFFD_FLAGS,
> .uffd_ioctls = BIT(_UFFDIO_COPY) |
> BIT(_UFFDIO_ZEROPAGE) |
> BIT(_UFFDIO_WRITEPROTECT) |
> BIT(_UFFDIO_CONTINUE) |
> BIT(_UFFDIO_POISON),
> .uffd_get_folio = shmem_uffd_get_folio,
> };
>
> No functional change expected at all after the whole series applied. There
> might be some slightly stricter check on uffd ops here and there in the
> last patch, but that really shouldn't stand out anywhere to anyone.
>
> For testing: besides the cross-compilation tests, I did also try with
> uffd-stress in a VM to measure any perf difference before/after the change;
> The static call becomes a pointer now. I really cannot measure anything
> different, which is more or less expected.
>
> Comments welcomed, thanks.
>
> Peter Xu (4):
> mm: Introduce vm_uffd_ops API
> mm/shmem: Support vm_uffd_ops API
> mm/hugetlb: Support vm_uffd_ops API
> mm: Apply vm_uffd_ops API to core mm
>
> include/linux/mm.h | 9 +++
> include/linux/userfaultfd_k.h | 83 ++++++++++++++++-----------
> mm/hugetlb.c | 19 +++++++
> mm/shmem.c | 25 +++++++++
> mm/userfaultfd.c | 102 ++++++++++++++++++++++++++--------
> 5 files changed, 181 insertions(+), 57 deletions(-)
>
> --
> 2.50.1
>
On Tue, Sep 30, 2025 at 03:49:34PM -0400, Liam R. Howlett wrote: > * Peter Xu <peterx@redhat.com> [250926 17:17]: > > [based on latest akpm/mm-new of Sep 26th, commit e612c80ae0aeb] > > > > v3 changelog: > > - Fixed checkpatch issues on spaces or typedef > > - Dropped uffd_copy() API > > - Refined commit messages here and there to reflect the removal of uffd_copy() > > > > v1: https://lore.kernel.org/r/20250620190342.1780170-1-peterx@redhat.com > > v2: https://lore.kernel.org/r/20250627154655.2085903-1-peterx@redhat.com > > > > This series is an alternative proposal of what Nikita proposed here on the > > initial three patches: > > > > https://lore.kernel.org/r/20250404154352.23078-1-kalyazin@amazon.com > > > > This is not yet relevant to any guest-memfd support, but paving way for it. > > It would be much easier to review this with the guest-memfd support in > this patch set. Any chance of including the target user? It should be something like what Nikita posted previously here against v1: https://lore.kernel.org/all/114133f5-0282-463d-9d65-3143aa658806@amazon.com/ I'll add the link into the cover letter when I repost. That formal patch logically will need to be reviewed from KVM side after this patch lands. Thanks, -- Peter Xu
© 2016 - 2025 Red Hat, Inc.