mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Kiryl Shutsemau <kirill@shutemov.name>, akpm@linux-foundation.org
Cc: usama.anjum@collabora.com, peterx@redhat.com, liam@infradead.org,
	ljs@kernel.org, vbabka@kernel.org, jannh@google.com,
	pfalcato@suse.de, rppt@kernel.org, surenb@google.com,
	mhocko@suse.com, shuah@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, stable@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH v4] fs/proc/task_mmu: fix PAGEMAP_SCAN written state for PMD holes
Date: Wed, 15 Jul 2026 15:47:00 +0200	[thread overview]
Message-ID: <f5700c45-9eab-47e1-946c-47d9a531bfeb@kernel.org> (raw)
In-Reply-To: <20260713091710.206548-1-kirill@shutemov.name>

On 7/13/26 11:17, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> 

Reading this, some of the details how this fits together are missing. You
capture some of that in the comment.

> PAGEMAP_SCAN reports an unpopulated PTE in a uffd-wp VMA as written, but
> a range with no page table at all -- a PMD hole -- is skipped:
> pagemap_scan_pte_hole() tests p->cur_vma_category, which never carries
> PAGE_IS_WRITTEN, so the hole is neither reported nor (under
> PM_SCAN_WP_MATCHING) armed.

Okay, the reason is that UFFD_FEATURE_WP_UNPOPULATED will make use of uffd
markers when protecting a range.

Seeing that marker gone translates to "MADV_DONTNEED was used". At least on
anonymous memory, looking at zap_install_uffd_wp_if_needed().

> 
> MADV_DONTNEED has fill-with-zeros semantics: it changes the contents of
> the range to zeroes (a subsequent read maps the zero page), which write

Only in MAP_PRIVATE | MAP_ANON mappings.

For e.g., MAP_PRIVATE file/shmem it will fallback to the original pagecache page
and there are no such guarantees.

> tracking must report as written. An anonymous THP is write-protected in
> place as a huge PMD, so a full-PMD MADV_DONTNEED clears it to pmd_none --
> a hole -- and the zeroing goes unreported. A write-tracking
> checkpoint/migration tool (e.g. CRIU) then treats the range as unchanged
> and keeps its previous contents, so after restore or live migration the
> process reads stale data instead of zeroes -- data corruption.

With UFFD_FEATURE_WP_UNPOPULATED, uffd-write-protecting a range without a PMD
table will end up allocating a page table (pgtable_populate_needed) that will be
filled with uffd-wp markers.

So what needs to happen is getting a THP collapsed there, to then zap the THP.

Or, of course, zapping a THP that was uffd-wp'ed. (which is what your test case
does IIUC)

> 
> Report a hole in a non-hugetlb uffd-wp VMA as written, matching the
> pte_none handling in pagemap_page_category(); the existing
> PM_SCAN_WP_MATCHING path then arms it via uffd_wp_range().

About which memory backing are walking about? Anon? Shmem? Something else?

> 
> hugetlb is excluded: pagemap_hugetlb_category() reports an empty hugetlb
> entry (huge_pte_none) as not-written, unlike pagemap_page_category(),
> which reports pte_none as written. pagemap_scan_pte_hole() fires for a
> hugetlb slot only when it has no page table; keeping that not-written
> matches how an allocated-but-empty hugetlb entry reads, so the hole and
> the empty-entry cases agree within the VMA.
> 
> Add a pagemap_ioctl selftest covering the anon-THP PMD-hole case.
> 


Do we really want to backport a test case? Usually we split them from the actual
fix.

> Reported-by: Sashiko AI review <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260707151349.92143-1-kirill@shutemov.name
> Fixes: 2bad466cc9d9 ("mm/uffd: UFFD_FEATURE_WP_UNPOPULATED")
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-fable-5
> ---
> 
> Changes since v3 [1]:
>   - Include <linux/mman.h> for MADV_COLLAPSE; <sys/mman.h> lacks it on
>     older glibc (e.g. 2.34), breaking the selftest build. Same approach
>     as fd5295afae91 ("selftests/mm: hmm-tests: include linux/mman.h to
>     access MADV_COLLAPSE"). Reported by Zenghui Yu.
> 
> [1] https://lore.kernel.org/all/20260709121629.205562-1-kirill@shutemov.name/
>  fs/proc/task_mmu.c                         | 27 +++++++++-
>  tools/testing/selftests/mm/pagemap_ioctl.c | 57 +++++++++++++++++++++-
>  2 files changed, 81 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index d45c729ab6bb..03ead4184546 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -3049,12 +3049,35 @@ static int pagemap_scan_pte_hole(unsigned long addr, unsigned long end,
>  {
>  	struct pagemap_scan_private *p = walk->private;
>  	struct vm_area_struct *vma = walk->vma;
> +	unsigned long categories;
>  	int ret, err;
>  
> -	if (!vma || !pagemap_scan_is_interesting_page(p->cur_vma_category, p))
> +	if (!vma)
>  		return 0;
>  
> -	ret = pagemap_scan_output(p->cur_vma_category, p, addr, &end);
> +	/*
> +	 * An unpopulated range with no page table -- e.g. a 2MB anon THP
> +	 * dropped via MADV_DONTNEED, which pagemap_page_category() never sees
> +	 * -- reads as written on a uffd-wp VMA, matching the pte_none case
> +	 * there. Reporting it also lets the PM_SCAN_WP_MATCHING arming below
> +	 * install markers (uffd_wp_range() allocates the page table under
> +	 * WP_UNPOPULATED), so the next scan sees it clean until re-written.
> +	 *
> +	 * hugetlb is excluded: pagemap_hugetlb_category() reports an empty
> +	 * hugetlb entry (huge_pte_none) as not-written, unlike
> +	 * pagemap_page_category(), which reports pte_none as written. This
> +	 * path fires for a hugetlb slot only when it has no page table;
> +	 * keeping that not-written matches how an allocated-but-empty
> +	 * hugetlb entry reads, so the two agree within the VMA.

Can that all be shortened?

"In a uffd-wp VMA, any unpopulated range is treated as written, as uffd-wp
registration populates page tables and installs markers with WP_UNPOPULATED. See
pte_none() handling in pagemap_page_category().

hugetlb handling differs, see pagemap_hugetlb_category().
"

> +	 */
> +	categories = p->cur_vma_category;
> +	if (userfaultfd_wp(vma) && !is_vm_hugetlb_page(vma))
> +		categories |= PAGE_IS_WRITTEN;


[...]

> +/*
> + * A 2MB anon THP dropped with MADV_DONTNEED leaves a pmd_none hole with no
> + * page table, which pagemap_page_category() never sees. PAGEMAP_SCAN must
> + * still report it as written on a uffd-wp VMA, via pagemap_scan_pte_hole().
> + */
> +static void unpopulated_thp_hole_test(void)
> +{
> +	long npages, written = 0, ret, i;
> +	struct page_region regions[16];
> +	char *area, *mem;
> +
> +	if (!hpage_size) {
> +		ksft_test_result_skip("%s THP not supported\n", __func__);
> +		return;
> +	}
> +	npages = hpage_size / page_size;
> +
> +	/* Get a PMD-aligned range so the range can be a single THP. */
> +	area = mmap(NULL, 2 * hpage_size, PROT_READ | PROT_WRITE,
> +		    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +	if (area == MAP_FAILED)
> +		ksft_exit_fail_msg("%s mmap failed\n", __func__);

Why exit the test? unpopulated_scan_test() seems to do that, but that is also
rather suboptimal. We can easily recover and continue executing tests.


> +	mem = (char *)(((unsigned long)area + hpage_size - 1) & ~(hpage_size - 1));
> +
> +	memset(mem, 1, hpage_size);
> +	if (madvise(mem, hpage_size, MADV_COLLAPSE) ||
> +	    !check_huge_anon(mem, 1, hpage_size)) {
> +		ksft_test_result_skip("%s could not form a THP\n", __func__);
> +		munmap(area, 2 * hpage_size);
> +		return;
> +	}
> +
> +	wp_init(mem, hpage_size);
> +
> +	/* Drop the whole PMD: it is cleared to a pmd_none hole. */
> +	if (madvise(mem, hpage_size, MADV_DONTNEED))
> +		ksft_exit_fail_msg("%s MADV_DONTNEED failed\n", __func__);
> +
> +	ret = pagemap_ioctl(mem, hpage_size, regions, 16, 0, 0,
> +			    PAGE_IS_WRITTEN, 0, 0, PAGE_IS_WRITTEN);
> +	if (ret < 0)
> +		ksft_exit_fail_msg("%s scan failed\n", __func__);
> +	for (i = 0; i < ret; i++)
> +		written += LEN(regions[i]);
> +
> +	ksft_test_result(written == npages,
> +			 "%s pmd-hole reported written (%ld of %ld)\n",
> +			 __func__, written, npages);
> +
> +	wp_free(mem, hpage_size);
> +	munmap(area, 2 * hpage_size);

There is quite some overlap with unpopulated_scan_test. Primarily the THP
allocation differs.

Couldn't we make the sequence similar by

(1) mmap
(2) wp_init(mem, mem_size); -> Populates page table
(3) memset(mem, 1, hpage_size); -> Allocates all entries
(4) MADV_COLLAPSE -> Get a THP
(5) MADV_DONTNEED -> Drop the THP

So couldn't we reuse most of unpopulated_scan_test in a reworked way?

> +}
> +
>  int sanity_tests(void)
>  {
>  	unsigned long long mem_size, vec_size;
> @@ -1610,7 +1664,7 @@ int main(int __attribute__((unused)) argc, char *argv[])
>  	if (!hugetlb_setup_default(4))
>  		ksft_print_msg("HugeTLB test will be skipped\n");
>  
> -	ksft_set_plan(118);
> +	ksft_set_plan(119);
>  
>  	page_size = getpagesize();
>  	hpage_size = read_pmd_pagesize();
> @@ -1790,6 +1844,7 @@ int main(int __attribute__((unused)) argc, char *argv[])
>  
>  	/* 18. Unpopulated pte scan-path consistency */
>  	unpopulated_scan_test();
> +	unpopulated_thp_hole_test();

Any reason this is not a unpopulated_thp_scan_test ?

-- 
Cheers,

David

  reply	other threads:[~2026-07-15 13:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  9:17 Kiryl Shutsemau
2026-07-15 13:47 ` David Hildenbrand (Arm) [this message]
2026-07-15 14:08   ` 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=f5700c45-9eab-47e1-946c-47d9a531bfeb@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=kernel-team@meta.com \
    --cc=kirill@shutemov.name \
    --cc=liam@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=usama.anjum@collabora.com \
    --cc=vbabka@kernel.org \
    /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

Powered by JetHome