From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: Ricardo Branco <rbranco@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API
Date: Fri, 23 Jan 2026 12:53:17 +0100 [thread overview]
Message-ID: <20260123115317.GA117991@pevik> (raw)
In-Reply-To: <CAEemH2c2pzwLcr+70_67oQ4aTqsTE004MnrLEPZgfvk-G1B+pg@mail.gmail.com>
> > > 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
next prev parent reply other threads:[~2026-01-23 11:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 5:40 [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API Li Wang via ltp
2026-01-23 9:45 ` Petr Vorel
2026-01-23 11:34 ` Li Wang via ltp
2026-01-23 11:53 ` Petr Vorel [this message]
2026-01-23 12:02 ` Li Wang via ltp
2026-01-23 12:25 ` Petr Vorel
2026-01-26 6:02 ` Li Wang via ltp
2026-01-27 12:48 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260123115317.GA117991@pevik \
--to=pvorel@suse.cz \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=rbranco@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.