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

[Peter Xu <peterx@redhat.com>]

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