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

[Li Wang]

> >       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