[LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Li Wang via ltp]

Commit 485a4cd2ba3 ("userfaultfd05: allow TCONF when UFFD-WP is unsupported")
added a TCONF path for missing UFFD-WP, but it relied on checking
uffdio_api.features after a failed ioctl (on RHEL-10).

That is not sufficient: it did not handle the case where UFFDIO_API
succeeds but the kernel does not advertise UFFD_FEATURE_PAGEFAULT_FLAG_WP
in the returned features mask.

So userfaultfd05 still fails on RHEL-9 s390x platform:

    userfaultfd05.c:106: TBROK: ioctl(3,((((2U|1U) << (((0+8)+8)+14)) |
		    (((0xAA)) << (0+8)) | ((((0x00))) << 0) |
		    ((((sizeof(struct uffdio_register)))) << ((0+8)+8)))),...)
		    failed: EINVAL (22)

Now, let's handle both behaviours by retrying UFFDIO_API with features=0
on EINVAL and treating a successful retry as "WP unsupported" (TCONF).
Also check the returned features mask after a successful UFFDIO_API and
skip when WP is not advertised.

And preserve the original errno so real UFFDIO_API failures are still
reported as 'TBROK | TERRNO'.

Follow-up: 485a4cd2ba3 ("userfaultfd05: allow TCONF when UFFD-WP is unsupported")
Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Ricardo Branco <rbranco@suse.com>
---
 .../kernel/syscalls/userfaultfd/userfaultfd05.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/testcases/kernel/syscalls/userfaultfd/userfaultfd05.c b/testcases/kernel/syscalls/userfaultfd/userfaultfd05.c
index 6cae45f20..4158b7b46 100644
--- a/testcases/kernel/syscalls/userfaultfd/userfaultfd05.c
+++ b/testcases/kernel/syscalls/userfaultfd/userfaultfd05.c
@@ -92,13 +92,24 @@ static void run(void)
 
 	uffdio_api.api = UFFD_API;
 	uffdio_api.features = UFFD_FEATURE_PAGEFAULT_FLAG_WP;
+
 	if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
-		if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
-			tst_brk(TCONF, "UFFD write-protect unsupported");
+		int err = errno;
+		if (err == EINVAL) {
+			uffdio_api.api = UFFD_API;
+			uffdio_api.features = 0;
+
+			if (ioctl(uffd, UFFDIO_API, &uffdio_api) == 0)
+				tst_brk(TCONF, "UFFD write-protect unsupported");
+		}
 
-		tst_brk(TBROK | TERRNO, "ioctl() on userfaultfd failed");
+		errno = err;
+		tst_brk(TBROK | TERRNO, "ioctl(UFFDIO_API) failed");
 	}
 
+	if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
+		tst_brk(TCONF, "UFFD write-protect unsupported");
+
 	uffdio_register.range.start = (unsigned long) page;
 	uffdio_register.range.len = page_size;
 	uffdio_register.mode = UFFDIO_REGISTER_MODE_WP;
-- 
2.52.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Petr Vorel]

Hi Li, Ricardo,

> Commit 485a4cd2ba3 ("userfaultfd05: allow TCONF when UFFD-WP is unsupported")
> added a TCONF path for missing UFFD-WP, but it relied on checking
> uffdio_api.features after a failed ioctl (on RHEL-10).

> That is not sufficient: it did not handle the case where UFFDIO_API
> succeeds but the kernel does not advertise UFFD_FEATURE_PAGEFAULT_FLAG_WP
> in the returned features mask.

> So userfaultfd05 still fails on RHEL-9 s390x platform:

>     userfaultfd05.c:106: TBROK: ioctl(3,((((2U|1U) << (((0+8)+8)+14)) |
> 		    (((0xAA)) << (0+8)) | ((((0x00))) << 0) |
> 		    ((((sizeof(struct uffdio_register)))) << ((0+8)+8)))),...)
> 		    failed: EINVAL (22)

> Now, let's handle both behaviours by retrying UFFDIO_API with features=0
> on EINVAL and treating a successful retry as "WP unsupported" (TCONF).
> Also check the returned features mask after a successful UFFDIO_API and
> skip when WP is not advertised.

...
>  	if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
> -		if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
> -			tst_brk(TCONF, "UFFD write-protect unsupported");
> +		int err = errno;
> +		if (err == EINVAL) {
> +			uffdio_api.api = UFFD_API;
> +			uffdio_api.features = 0;
> +
> +			if (ioctl(uffd, UFFDIO_API, &uffdio_api) == 0)
> +				tst_brk(TCONF, "UFFD write-protect unsupported");
> +		}

Wouldn't be better in this case to check kconfig for
CONFIG_HAVE_ARCH_USERFAULTFD_WP (untested, but it should work

Back to our discussion about how often using kconfig [1]. While I prefer to
avoid using it for tristate (kernel might be configured but module missing), but
here is just a feature.

[1] https://lore.kernel.org/ltp/CAASaF6wOSvi+07Pq5O6+f1Hkrq6WWMgpCaooJxWrO9uOvRM3pw@mail.gmail.com/

But I'm ok with it if you prefer exact check.
Reviewed-by: Petr Vorel <pvorel@suse.cz>

> -		tst_brk(TBROK | TERRNO, "ioctl() on userfaultfd failed");
> +		errno = err;
> +		tst_brk(TBROK | TERRNO, "ioctl(UFFDIO_API) failed");
+1
>  	}

Kind regards,
Petr

> +	if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
> +		tst_brk(TCONF, "UFFD write-protect unsupported");
> +
>  	uffdio_register.range.start = (unsigned long) page;
>  	uffdio_register.range.len = page_size;
>  	uffdio_register.mode = UFFDIO_REGISTER_MODE_WP;

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Li Wang via ltp]

> >       if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
> > -             if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
> > -                     tst_brk(TCONF, "UFFD write-protect unsupported");
> > +             int err = errno;
> > +             if (err == EINVAL) {
> > +                     uffdio_api.api = UFFD_API;
> > +                     uffdio_api.features = 0;
> > +
> > +                     if (ioctl(uffd, UFFDIO_API, &uffdio_api) == 0)
> > +                             tst_brk(TCONF, "UFFD write-protect unsupported");
> > +             }
>
> Wouldn't be better in this case to check kconfig for
> CONFIG_HAVE_ARCH_USERFAULTFD_WP (untested, but it should work

That's true, it would be simpler, let's go with this method.

> Back to our discussion about how often using kconfig [1]. While I prefer to
> avoid using it for tristate (kernel might be configured but module missing), but
> here is just a feature.

> [1] https://lore.kernel.org/ltp/CAASaF6wOSvi+07Pq5O6+f1Hkrq6WWMgpCaooJxWrO9uOvRM3pw@mail.gmail.com/

I don’t think there is a single “standard” answer for feature detection;
it really depends on the specific situation.

For the UFFD-WP feature the situation is: there isn’t really a boot
parameter or runtime knob that disables UFFD-WP independently once the
interface is present. Given that, a simpler approach is to rely on Kconfig
checks.

This is especially relevant here because different kernels report “WP
unsupported” differently (e.g. return -1/EINVAL vs return 0 with a
different feature mask), which makes runtime-based detection more
complicated.


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Petr Vorel]

> > >       if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
> > > -             if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP))
> > > -                     tst_brk(TCONF, "UFFD write-protect unsupported");
> > > +             int err = errno;
> > > +             if (err == EINVAL) {
> > > +                     uffdio_api.api = UFFD_API;
> > > +                     uffdio_api.features = 0;
> > > +
> > > +                     if (ioctl(uffd, UFFDIO_API, &uffdio_api) == 0)
> > > +                             tst_brk(TCONF, "UFFD write-protect unsupported");
> > > +             }

> > Wouldn't be better in this case to check kconfig for
> > CONFIG_HAVE_ARCH_USERFAULTFD_WP (untested, but it should work

> That's true, it would be simpler, let's go with this method.

> > Back to our discussion about how often using kconfig [1]. While I prefer to
> > avoid using it for tristate (kernel might be configured but module missing), but
> > here is just a feature.

> > [1] https://lore.kernel.org/ltp/CAASaF6wOSvi+07Pq5O6+f1Hkrq6WWMgpCaooJxWrO9uOvRM3pw@mail.gmail.com/

> I don’t think there is a single “standard” answer for feature detection;
> it really depends on the specific situation.

> For the UFFD-WP feature the situation is: there isn’t really a boot
> parameter or runtime knob that disables UFFD-WP independently once the
> interface is present. Given that, a simpler approach is to rely on Kconfig
> checks.

> This is especially relevant here because different kernels report “WP
> unsupported” differently (e.g. return -1/EINVAL vs return 0 with a
> different feature mask), which makes runtime-based detection more
> complicated.

Yes, for the discussion when to use I'd propose to *not* use kconfig if:
* boot parameter to enable/disable exist
* check for tristate (functionality which can be compiled as module)
* kernel new functionality which is unlikely to be backported (use .min_kver instead)

Unless some objection, I'll post a patch for ground rules.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Li Wang via ltp]

> Yes, for the discussion when to use I'd propose to *not* use kconfig if:

> * boot parameter to enable/disable exist
> * check for tristate (functionality which can be compiled as module)
> * kernel new functionality which is unlikely to be backported (use .min_kver instead)

That sounds great to me.

And, plus one more:
   * kconfig file may be unavailable for some reasons


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Petr Vorel]

> > Yes, for the discussion when to use I'd propose to *not* use kconfig 
Maybe to correct myself:

*Use* kconfig if there is no other way to detect the functionality [1].
We prefer to use kconfig detection, but do *not* use kconfig when there is
another way to detect the functionality (e.g. via detecting functionality via
/proc|sys) *and* and one of these three rules:

> > * boot parameter to enable/disable exist
* allow to disable via kernel boot parameter or via /sys file
=> because it can be disabled
> > * check for tristate (functionality which can be compiled as module)
=> modul might not be available
> > * kernel new functionality which is unlikely to be backported (use .min_kver instead)
=> probably faster

> That sounds great to me.

Thank you!

> And, plus one more:
>    * kconfig file may be unavailable for some reasons

Yes, but we gave up on this (or at least Cyril) [1]:

	As for the missing config there is 95 testcases that have needs_kconfigs
	set at this moment and the number is growing steadily. I would argue
	that you cannot run LTP without having config available. And the config
	location is autodetected on common distributions as well.

me: + at least 2 IMA tests require kconfig via tst_require_kconfigs().

Therefore I accepted it and I'm not against using kconfig. But I would prefer
using it only when it works reliably (100%).

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/aV6DCbns02E4BCTj@yuki.lan/

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Li Wang via ltp]

On Fri, Jan 23, 2026 at 8:25 PM Petr Vorel <pvorel@suse.cz> wrote:

> > > Yes, for the discussion when to use I'd propose to *not* use kconfig
> Maybe to correct myself:
>
> *Use* kconfig if there is no other way to detect the functionality [1].
> We prefer to use kconfig detection, but do *not* use kconfig when there is
> another way to detect the functionality (e.g. via detecting functionality
> via
> /proc|sys) *and* and one of these three rules:
>
> > > * boot parameter to enable/disable exist
> * allow to disable via kernel boot parameter or via /sys file
> => because it can be disabled
> > > * check for tristate (functionality which can be compiled as module)
> => modul might not be available
> > > * kernel new functionality which is unlikely to be backported (use
> .min_kver instead)
> => probably faster
>
> > That sounds great to me.
>
> Thank you!
>
> > And, plus one more:
> >    * kconfig file may be unavailable for some reasons
>
> Yes, but we gave up on this (or at least Cyril) [1]:
>
>         As for the missing config there is 95 testcases that have
> needs_kconfigs
>         set at this moment and the number is growing steadily. I would
> argue
>         that you cannot run LTP without having config available. And the
> config
>         location is autodetected on common distributions as well.
>
> me: + at least 2 IMA tests require kconfig via tst_require_kconfigs().
>
> Therefore I accepted it and I'm not against using kconfig. But I would
> prefer
> using it only when it works reliably (100%).
>

Make sense!


> Kind regards,
> Petr
>
> [1] https://lore.kernel.org/ltp/aV6DCbns02E4BCTj@yuki.lan/
>
>

-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API

[Cyril Hrubis]

Hi!
Looks good.

Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp