On Tue, Sep 16, 2025 at 10:27 AM David P. Reed <dpreed@deepplum.com> wrote:

> Than -
>
> Just to clarify -
> Looking at the man page for UFFDIO_API, there are two "feature bits" that
> indicate cases where "minor" handling is now supported, and can be enabled.
> UFFD_FEATURE_MINOR_HUGETLBFS and UFFD_FEATURE_MINOR_SHMEM
> In my reading of the documents, these seem to imply that before they were
> added as new features, that MAP_PRIVATE|MAP_ANONYMOUS mappings were
> supported, and that the "new" additions to the MINOR mode were just for
> HUGETLBFS and MAP_SHARED cases.
>

Actually minor fault support didn't exist at all before those two features
were added. :)

You are right that userfaultfd's use of "minor fault" is (unfortunately)
slightly different from the meaning in other contexts. I think the more
normal meaning is, faults which do not incur I/O (i.e., swap faults and
file faults [i.e., faults on non-swap-backed pages] are major, other faults
are minor).

For userfaultfd, a minor fault is a fault where the page already exists in
the page cache, but the page table entry wasn't setup. I don't think that
scenario can ever happen for anonymous, private mappings, so it doesn't
really make sense to be able to register such mappings in this mode. If you
create a mapping with mmap(MAP_ANON|MAP_PRIVATE) and then access it (read
or write), that fault requires allocation of a new page, so userfaultfd
does not consider that a "minor fault". My recollection though is if you
make a file on tmpfs or hugetlbfs, fallocate() it or whatever, and you
MAP_PRIVATE that file, *that* registration will work.


>
> It seems odd that anonymous page faults and COW would not be handled,
> given that context.
>
> Anyway, that's unclear in any of the documentation. This just adds to my
> last response where I explain my use case.
>
>
>