Re: [PATCH v2] selftests/mm: Fix UFFDIO_API usage with proper two-step feature negotiation

[Nadav Amit <nadav.amit@gmail.com>]

> On 24 Jun 2025, at 11:22, David Hildenbrand <david@redhat.com> wrote:
> 
> On 24.06.25 10:07, David Hildenbrand wrote:
>>> 
>> Is that actually required?
>> The man page explicitly documents:
>> "       EINVAL A  previous  UFFDIO_API  call already enabled one or more
>> features for this userfaultfd.  Calling UFF‐
>>                DIO_API twice, the first time with no features set, is
>> explicitly allowed as per the two-step  feature
>>                detection handshake.
>> "
>> So if that doesn't work, something might be broken.
> 
> CCing Nadav and Peter:
> 
> Could it be that
> 
> commit 22e5fe2a2a279d9a6fcbdfb4dffe73821bef1c90
> Author: Nadav Amit <nadav.amit@gmail.com>
> Date:   Thu Sep 2 14:58:59 2021 -0700
> 
>    userfaultfd: prevent concurrent API initialization
>        userfaultfd assumes that the enabled features are set once and never
>    changed after UFFDIO_API ioctl succeeded.
>        However, currently, UFFDIO_API can be called concurrently from two
>    different threads, succeed on both threads and leave userfaultfd's
>    features in non-deterministic state.  Theoretically, other uffd operations
>    (ioctl's and page-faults) can be dispatched while adversely affected by
>    such changes of features.
>        Moreover, the writes to ctx->state and ctx->features are not ordered,
>    which can - theoretically, again - let userfaultfd_ioctl() think that
>    userfaultfd API completed, while the features are still not initialized.
>        To avoid races, it is arguably best to get rid of ctx->state.  Since there
>    are only 2 states, record the API initialization in ctx->features as the
>    uppermost bit and remove ctx->state.
> 
> Accidentally broke the documented two-step handshake in the man page where we
> can avoid closing + reopening the fd?

I agree the code is not correct (and my patch didn’t address this issue),
but I don’t see it broke it either.

Unless I’m missing something the code before my patch, when
uffdio_api.features == 0, also set ctx->state to UFFD_STATE_RUNNING, which
meant another invocation would see (ctx->state != UFFD_STATE_WAIT_API) and
fail.

> 
> Without testing, the following might fix it if I am right:
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 22f4bf956ba1c..f03e7c980e1c5 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -1944,9 +1944,9 @@ static int userfaultfd_move(struct userfaultfd_ctx *ctx,
> static int userfaultfd_api(struct userfaultfd_ctx *ctx,
>                           unsigned long arg)
> {
> +       unsigned int new_features, old_features = 0;
>        struct uffdio_api uffdio_api;
>        void __user *buf = (void __user *)arg;
> -       unsigned int ctx_features;
>        int ret;
>        __u64 features;
> @@ -1990,9 +1990,12 @@ static int userfaultfd_api(struct userfaultfd_ctx *ctx,
>                goto out;
>         /* only enable the requested features for this uffd context */
> -       ctx_features = uffd_ctx_features(features);
> +       new_features = uffd_ctx_features(features);
> +       /* allow two-step handshake */
> +       if (userfaultfd_is_initialized(ctx))
> +               old_features = UFFD_FEATURE_INITIALIZED;
>        ret = -EINVAL;
> -       if (cmpxchg(&ctx->features, 0, ctx_features) != 0)
> +       if (cmpxchg(&ctx->features, old_features, new_features) != old_features)
>                goto err_out;
>         ret = 0;

I am not sure it is right since you would return EINVAL in this case.
It also looks a bit overly complicated - are you concerned about a race?
My whole concern about race was that somebody would exploit it to
overcome non-cooperative UFFD (IIRC).

So perhaps just add a check for the case features if 0 and be done with
it? Something like adding:

	ret = 0;
	if (ctx->features == 0 && features == 0)
		goto err_out; 		/* no error but copying of uffdio_api required */

before enabling the requested features for this uffd context.