[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0XuUBqBvUvhQzGn@x1n>
Date: Tue, 26 Nov 2024 10:50:40 -0500
From: Peter Xu <peterx@...hat.com>
To: stsp <stsp2@...dex.ru>
Cc: Axel Rasmussen <axelrasmussen@...gle.com>,
Linux kernel <linux-kernel@...r.kernel.org>,
Muhammad Usama Anjum <usama.anjum@...labora.com>,
Mike Rapoport <rppt@...nel.org>
Subject: Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL
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
Powered by blists - more mailing lists