Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL

From: Peter Xu
Date: Tue Nov 26 2024 - 10:51:30 EST


On Tue, Nov 26, 2024 at 10:39:19AM +0300, stsp wrote:
> Please, just why do you have that UFFD_API
> const? Only to call every screw-up like this
> one, a sailed ship? :)
> Why not to add UFFD_API_v2?
> Then UFFD_API_v3?
> Full binary and source compatibility is
> therefore preserved, you only need to
> update the man page to document the
> latest one.

We could. I'd say we only need UFFDIO_FEATURE to fetch the features, if we
want the interface clean. I just never feel strongly to add it.

"Creating two fds" is indeed awkward, but that isn't too bad either when
the userapp can easily wrap a function to do that, open+close the fd
within. Actually that's what our unit test was doing.

int uffd_get_features(uint64_t *features)
{
struct uffdio_api uffdio_api = { .api = UFFD_API, .features = 0 };
/*
* This should by default work in most kernels; the feature list
* will be the same no matter what we pass in here.
*/
int fd = uffd_open(UFFD_USER_MODE_ONLY);

if (fd < 0)
/* Maybe the kernel is older than user-only mode? */
fd = uffd_open(0);

if (fd < 0)
return fd;

if (ioctl(fd, UFFDIO_API, &uffdio_api)) {
close(fd);
return -errno;
}

*features = uffdio_api.features;
close(fd);

return 0;
}

--
Peter Xu