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

[Peter Xu <peterx@redhat.com>]

On Sat, Nov 23, 2024 at 06:13:01PM +0300, stsp wrote:
> Hello.
> 
> I tried to use userfaultfd and got
> that strange result: when I first do
> UFFDIO_API ioctl with features = 0,
> it succeeds. I check the needed
> features, and they are all in place.
> But on the second step, where I
> request the needed features,
> UFFDIO_API gives -EINVAL no matter
> what features I requested (or even
> set features to 0 again).
> 
> A quick look into the kernel code
> suggests that the problem is that
> uffd_ctx_features() doesn't check
> user_features for being 0, and just
> sets UFFD_FEATURE_INITIALIZED
> with no features at all. After that,
> userfaultfd_api() should always
> fail with -EINVAL when doing this:
> 
> ctx_features = uffd_ctx_features(features);
> ret = -EINVAL;
> if (cmpxchg(&ctx->features, 0, ctx_features) != 0)
>         goto err_out;
> 
> But I haven't checked my finding
> by rebuilding the kernel.
> So is this broken or am I missing
> something?

I agree it's slightly confusing but it's intended.  It's like that since
the start, so I think we should still keep the behavior.

The userapp needs to create one extra userfaultfd to detect supported
features in the kernel.  To use it after a probe request, you'll need to
close() the fd, redo the userfaultfd syscall to create another fd.

The kernel cannot assume features==0 to be a pure query, because not all
userfaultfd features requires setting of a feature bit. E.g., the default
anonymous missing traps doesn't require any feature bit to set.  So the
initial UFFDIO_API(features=0) is the enablement of such feature.

Thanks,

-- 
Peter Xu