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.