Kernel KVM virtualization development
 help / color / mirror / Atom feed
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

  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