[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250926211650.525109-1-peterx@redhat.com>
Date: Fri, 26 Sep 2025 17:16:46 -0400
From: Peter Xu <peterx@...hat.com>
To: linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: Axel Rasmussen <axelrasmussen@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
James Houghton <jthoughton@...gle.com>,
Nikita Kalyazin <kalyazin@...zon.com>,
David Hildenbrand <david@...hat.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Ujwal Kundur <ujwal.kundur@...il.com>,
Mike Rapoport <rppt@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
peterx@...hat.com,
Andrea Arcangeli <aarcange@...hat.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Michal Hocko <mhocko@...e.com>,
Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>,
Hugh Dickins <hughd@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>
Subject: [PATCH v3 0/4] mm/userfaultfd: modulize memory types
[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
Powered by blists - more mailing lists