Re: [PATCH v8 15/15] Documentation/userfaultfd: document RWP working set tracking

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Documentation incorrectly claims UFFDIO_API returns the supported features bitmask on EINVAL
--

commit b47603d883cc00fed0a038162bec7702caba77c6
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

Documentation/userfaultfd: document RWP working set tracking

This commit adds documentation for the new UFFDIO_REGISTER_MODE_RWP feature,
covering sync and async fault models, UFFDIO_RWPROTECT semantics,
UFFD_FEATURE_RWP_ASYNC, and UFFDIO_SET_MODE runtime mode flips.

> diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
> index 1e533639fd509..69836e39aa0b6 100644
> --- a/Documentation/admin-guide/mm/userfaultfd.rst
> +++ b/Documentation/admin-guide/mm/userfaultfd.rst
[ ... ]
> @@ -307,6 +307,253 @@ transparent to the guest, we want that same address range to act as if it was
[ ... ]
> +**Feature availability:**
> +
> +RWP is built on top of two kernel primitives: a spare PTE bit owned by
> +userfaultfd (``CONFIG_HAVE_ARCH_USERFAULTFD_WP``) and architecture support
> +for present-but-inaccessible PTEs (``CONFIG_ARCH_HAS_PTE_PROTNONE``). When both
> +are available on a 64-bit kernel, the build selects
> +``CONFIG_USERFAULTFD_RWP=y`` and the ``VM_UFFD_RWP`` VMA flag becomes
> +available.
> +
> +``UFFD_FEATURE_RWP`` and ``UFFD_FEATURE_RWP_ASYNC`` are unavailable when
> +the running kernel or architecture does not support them — for example
> +32-bit kernels (where ``VM_UFFD_RWP`` is unavailable), kernels built
> +without ``CONFIG_USERFAULTFD_RWP``, and architectures whose ptes cannot
> +carry the uffd bit at runtime (e.g. riscv without the ``SVRSW60T59B``
> +extension). Requesting an unsupported feature in
> +``uffdio_api.features`` makes ``UFFDIO_API`` fail with ``EINVAL`` and
> +leaves the userfaultfd context uninitialized; the bitmask returned in
> +``uffdio_api.features`` then advertises the features the kernel does
> +support. The recommended probe sequence is therefore to open a

[Severity: Medium]
Does UFFDIO_API actually return the supported features bitmask on EINVAL?

Userspace programs written according to the Feature availability section
will expect the uffdio_api.features out-parameter to contain the supported
feature mask after a failure (EINVAL). Because the kernel actually returns
0, such programs will incorrectly conclude that the kernel supports no
features at all if they rely on the error path to discover capabilities.

> +throwaway userfaultfd, call ``UFFDIO_API`` once with ``features = 0``,
> +inspect the returned bitmask, close that fd, then open the real one
> +and call ``UFFDIO_API`` again with only the supported features set.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703133615.1039465-1-kirill@shutemov.name?part=15