Explain the difference created by UFFD_FEATURE_WP_ASYNC to the write protection (UFFDIO_WRITEPROTECT_MODE_WP) mode. Suggested-by: Suggested-by: Peter Xu <peterx@xxxxxxxxxx> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx> --- Changes in v11: - Update the documentation from reviews entirely from Peter --- Documentation/admin-guide/mm/userfaultfd.rst | 21 ++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 7dc823b56ca4..404d8aa8f09f 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -219,6 +219,27 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was used. +If the userfaultfd context (that has ``UFFDIO_REGISTER_MODE_WP`` registered +against) has ``UFFD_FEATURE_WP_ASYNC`` feature enabled, it will work in +async write protection mode. It can be seen as a more accurate version of +soft-dirty tracking, meanwhile the results will not be easily affected by +other operations like vma merging. + +Comparing to the generic mode, the async mode will not generate any +userfaultfd message when the protected memory range is written. Instead, the +kernel will automatically resolve the page fault immediately by dropping the +uffd-wp bit in the pgtables. The user app can collect the "written/dirty" +status by looking up the uffd-wp bit for the pages being interested in +/proc/pagemap. + +The page will be under track of uffd-wp async mode until the page is explicitly +write-protected by ``UFFDIO_WRITEPROTECT`` ioctl with the mode flag +``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault that was +tracked by async mode userfaultfd-wp is invalid. + +Currently ``UFFD_FEATURE_WP_ASYNC`` only support anonymous and shmem. Hugetlb is +not yet supported. + QEMU/KVM ======== -- 2.39.2
