From: sashiko-bot@kernel.org
To: "Kiryl Shutsemau" <kirill@shutemov.name>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v9 14/15] selftests/mm: add userfaultfd RWP tests
Date: Mon, 06 Jul 2026 09:19:26 +0000 [thread overview]
Message-ID: <20260706091926.91A2E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706084805.8400-15-kirill@shutemov.name>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The uffd selftests unconditionally call `err()` if `madvise(MADV_NOHUGEPAGE)` fails for RWP tests, which will abort the entire test suite on kernels compiled with `CONFIG_TRANSPARENT_HUGEPAGE=n`.
- [Medium] The `rwp-fork-pin` and `rwp-mprotect` tests will silently pass if a kernel bug causes the `uffd-wp` marker to be completely dropped instead of preserved.
--
commit c7d4aef17412fdd00834c4bcc5b4fbabc6db2f28
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>
Date: Mon Jul 6 08:48:03 2026 +0000
selftests/mm: add userfaultfd RWP tests
Coverage for UFFDIO_REGISTER_MODE_RWP and UFFDIO_RWPROTECT. All tests
run against anon, shmem, shmem-private, hugetlb, and hugetlb-private
memory, except rwp-fork-pin which is anon-only.
> diff --git a/tools/testing/selftests/mm/uffd-unit-tests.c b/tools/testing/selftests/mm/uffd-unit-tests.c
> index a6c14109e8188..bd3b9f41ee354 100644
> --- a/tools/testing/selftests/mm/uffd-unit-tests.c
> +++ b/tools/testing/selftests/mm/uffd-unit-tests.c
[ ... ]
> +static void uffd_rwp_mprotect_test(uffd_global_test_opts_t *gopts,
> + uffd_test_args_t *args)
> +{
[ ... ]
> + /* Round-trip mprotect(): PROT_NONE -> PROT_READ|PROT_WRITE */
> + if (mprotect(gopts->area_dst, nr_pages * page_size, PROT_NONE))
> + err("mprotect() PROT_NONE");
> + if (mprotect(gopts->area_dst, nr_pages * page_size,
> + PROT_READ | PROT_WRITE))
> + err("mprotect() PROT_READ|PROT_WRITE");
> +
> + /* Touch every page. Async RWP must auto-resolve each fault. */
> + for (p = 0; p < nr_pages; p++) {
> + volatile char *page = gopts->area_dst + p * page_size;
> + (void)*page;
> + }
[Severity: Medium]
Will this test falsely pass if mprotect() completely drops the uffd-wp
marker? Since the test accesses the pages expecting async faults to clear the
markers, but doesn't assert that the markers survived the mprotect()
round-trip first, a kernel bug dropping the protection might let the access
silently succeed and leave the marker clear.
[ ... ]
> +static void uffd_rwp_fork_pin_test(uffd_global_test_opts_t *gopts,
> + uffd_test_args_t *args)
> +{
[ ... ]
> + child = fork();
> + if (child < 0)
> + err("fork");
> + if (child == 0) {
> + volatile char c;
> + int cfd;
> +
> + /*
> + * Read the pinned page. Only reaches the fault path if the
> + * child PTE is protnone + uffd; async mode auto-resolves and
> + * clears the uffd bit. If copy_present_page() dropped
> + * PAGE_NONE, the read would silently succeed and the bit
> + * would still be set.
> + */
> + c = *(volatile char *)gopts->area_dst;
> + (void)c;
> +
> + cfd = pagemap_open();
> + value = pagemap_get_entry(cfd, gopts->area_dst);
> + close(cfd);
> + _exit((value & PM_UFFD_WP) ? 1 : 0);
> + }
[Severity: Medium]
Could this test also falsely pass if copy_present_page() drops the uffd-wp
marker completely? The child touches the page and verifies the marker is
clear, but it doesn't verify the marker was correctly preserved prior to the
access.
[ ... ]
> @@ -1814,6 +2684,20 @@ int main(int argc, char *argv[])
> uffd_test_skip(errmsg);
> continue;
> }
> + /*
> + * RWP tracks protection on ptes; a THP-backed shmem/anon
> + * range (e.g. shmem_enabled=always) would split on
> + * rwprotect and change behaviour under the test. Keep
> + * such ranges off THP. hugetlb is huge by definition and
> + * rejects MADV_NOHUGEPAGE, so skip it.
> + */
> + if ((test->uffd_feature_required & UFFD_FEATURE_RWP) &&
> + !(mem_type->mem_flag & (MEM_HUGETLB | MEM_HUGETLB_PRIVATE))) {
> + unsigned long len = gopts.nr_pages * gopts.page_size;
> +
> + if (madvise(gopts.area_dst, len, MADV_NOHUGEPAGE))
> + err("madvise(MADV_NOHUGEPAGE)");
[Severity: Medium]
Will this unconditional error check on madvise() abort the entire test suite
on kernels lacking THP support? On a kernel compiled with
CONFIG_TRANSPARENT_HUGEPAGE=n, madvise(MADV_NOHUGEPAGE) returns -EINVAL,
which would cause err() to exit the process instead of gracefully continuing
or skipping the test.
> + }
> test->uffd_fn(&gopts, &args);
> uffd_test_ctx_clear(&gopts);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706084805.8400-1-kirill@shutemov.name?part=14
next prev parent reply other threads:[~2026-07-06 9:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 8:47 [PATCH v9 00/15] userfaultfd: working set tracking for VM guest memory Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 01/15] mm: decouple protnone helpers from CONFIG_NUMA_BALANCING Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 02/15] mm: rename uffd-wp PTE bit macros to uffd Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 03/15] mm: rename uffd-wp PTE accessors " Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 04/15] userfaultfd: test uffd VMA flags through the vma_flags_t API Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 05/15] mm: add VM_UFFD_RWP VMA flag Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 06/15] mm: add MM_CP_UFFD_RWP change_protection() flag Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 07/15] mm: preserve RWP marker across PTE rewrites Kiryl Shutsemau
2026-07-06 9:20 ` sashiko-bot
2026-07-06 8:47 ` [PATCH v9 08/15] mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP Kiryl Shutsemau
2026-07-06 8:47 ` [PATCH v9 09/15] userfaultfd: add UFFDIO_REGISTER_MODE_RWP and UFFDIO_RWPROTECT plumbing Kiryl Shutsemau
2026-07-06 9:06 ` sashiko-bot
2026-07-06 8:47 ` [PATCH v9 10/15] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP Kiryl Shutsemau
2026-07-06 9:22 ` sashiko-bot
2026-07-06 8:48 ` [PATCH v9 11/15] mm/pagemap: add PAGE_IS_ACCESSED for RWP tracking Kiryl Shutsemau
2026-07-06 9:15 ` sashiko-bot
2026-07-06 12:57 ` Usama Arif
2026-07-06 13:52 ` Kiryl Shutsemau
2026-07-06 8:48 ` [PATCH v9 12/15] userfaultfd: add UFFD_FEATURE_RWP_ASYNC for async fault resolution Kiryl Shutsemau
2026-07-06 8:48 ` [PATCH v9 13/15] userfaultfd: add UFFDIO_SET_MODE for runtime sync/async toggle Kiryl Shutsemau
2026-07-06 9:20 ` sashiko-bot
2026-07-06 8:48 ` [PATCH v9 14/15] selftests/mm: add userfaultfd RWP tests Kiryl Shutsemau
2026-07-06 9:19 ` sashiko-bot [this message]
2026-07-06 10:49 ` [PATCH v9.1 " Kiryl Shutsemau
2026-07-06 8:48 ` [PATCH v9 15/15] Documentation/userfaultfd: document RWP working set tracking Kiryl Shutsemau
2026-07-06 10:56 ` Addressing Sashiko AI review Kiryl Shutsemau
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=20260706091926.91A2E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox