@@ -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
========
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@redhat.com> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> --- Changes in v11: - Update the documentation from reviews entirely from Peter --- Documentation/admin-guide/mm/userfaultfd.rst | 21 ++++++++++++++++++++ 1 file changed, 21 insertions(+)