admin-guide/mm/userfaultfd.rst

8 Userfaults allow the implementation of on-demand paging from userland
38 Vmas are not suitable for page- (or hugepage) granular fault tracking
48 is a corner case that would currently return ``-EBUSY``).
54 ----------------------
63 - Any user can always create a userfaultfd which traps userspace page faults
67 - In order to also trap kernel page faults for the address space, either the
84 --------------------------
101 - The ``UFFD_FEATURE_EVENT_*`` flags indicate that various other events
103   detail below in the `Non-cooperative userfaultfd`_ section.
105 - ``UFFD_FEATURE_MISSING_HUGETLBFS`` and ``UFFD_FEATURE_MISSING_SHMEM``
111 - ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports
116 - ``UFFD_FEATURE_MOVE`` indicates that the kernel supports moving an
138 user-faulted page.
141 --------------------
145 - ``UFFDIO_COPY`` atomically copies some existing page contents from
148 - ``UFFDIO_ZEROPAGE`` atomically zeros the new page.
150 - ``UFFDIO_CONTINUE`` maps an existing, previously-populated page.
153 see a half-populated page, since readers will keep userfaulting until the
163 - For ``UFFDIO_REGISTER_MODE_MISSING`` faults, the fault needs to be
167   decide what content to provide before the faulting thread continues.
169 - For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
177 - You can tell which kind of fault occurred by examining
181 - None of the page-delivering ioctls default to the range that you
185 - You get the address of the access that triggered the missing page
191 - Be sure to test for all errors including
196 ---------------------------
219 difference between writes into a WP area and into a !WP area.  The
225 Userfaultfd write-protect mode currently behave differently on none ptes
229 (e.g. when pages are missing and not populated).  For file-backed memories
233 as long as the page range was write-protected before.  Such a message will
237 memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
246 write-protected (so future writes will also result in a WP fault). These ioctls
251 any vma registered with write-protection will work in async mode rather
255 happens, meanwhile the write-protection will be resolved automatically by
256 the kernel.  It can be seen as a more accurate version of soft-dirty
259   - The dirty result will not be affected by vma changes (e.g. vma
262   - It supports range operations by default, so one can enable tracking on
265   - Dirty information will not get lost if the pte was zapped due to
268   - Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
269     set; dirty when uffd-wp bit cleared), it has different semantics on
272     dirtying of memory by dropping uffd-wp bit during the procedure.
275 uffd-wp bit for the pages being interested in /proc/pagemap.
277 The page will not be under track of uffd-wp async mode until the page is
278 explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
280 that was tracked by async mode userfaultfd-wp is invalid.
282 When userfaultfd-wp async mode is used alone, it can be applied to all
286 ---------------------------
335 the ``userfaultfd`` and receives the fault address (or ``-EAGAIN`` in case the
352 doesn't need to keep any per-page state bitmap relative to the live
353 migration around and a single per-page bitmap has to be maintained in
363 Non-cooperative userfaultfd
382 	non-cooperative process moves a virtual memory area to a
414 asynchronously and the non-cooperative process resumes execution as
418 return ``-ENOSPC`` when the monitored process exits at the time of
419 ``UFFDIO_COPY``, and ``-ENOENT``, when the non-cooperative process has changed
424 single threaded non-cooperative ``userfaultfd`` manager implementations. A