linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Wei Yang <richard.weiyang@gmail.com>,
	akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
	ziy@nvidia.com, baolin.wang@linux.alibaba.com
Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [Patch v2] selftests/mm: check content to see whether mremap corrupt data
Date: Mon, 1 Sep 2025 09:22:44 +0200	[thread overview]
Message-ID: <f8e942de-1a50-412e-9020-1bc901b4243b@redhat.com> (raw)
In-Reply-To: <20250831022701.2595-1-richard.weiyang@gmail.com>

On 31.08.25 04:27, Wei Yang wrote:

Subject: "selftests/mm: verify page content after remapping PMD through 
PTEs"

> After mremap(), add a check on content to see whether mremap corrupt
> data.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> 
> ---
> v2: add check on content instead of just test backed folio

I'm confused, don't we have that exact check later in the function?

Your v1 might have been better, unless I am missing something.

> ---
>   tools/testing/selftests/mm/split_huge_page_test.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
> index 10ae65ea032f..229b6dcabece 100644
> --- a/tools/testing/selftests/mm/split_huge_page_test.c
> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
> @@ -423,10 +423,14 @@ static void split_pte_mapped_thp(void)
>   
>   	/* smap does not show THPs after mremap, use kpageflags instead */
>   	thp_size = 0;
> -	for (i = 0; i < pagesize * 4; i++)
> +	for (i = 0; i < pagesize * 4; i++) {
> +		if (pte_mapped[i] != (char)i)
> +			ksft_exit_fail_msg("%ld byte corrupted\n", i);
> +
>   		if (i % pagesize == 0 &&
>   		    is_backed_by_folio(&pte_mapped[i], pmd_order, pagemap_fd, kpageflags_fd))
>   			thp_size++;
> +	}
>   
>   	if (thp_size != 4)
>   		ksft_exit_fail_msg("Some THPs are missing during mremap\n");

I'm a bit confused with this test in general.

We do a

pte_mapped = mremap(one_page, pagesize, pagesize, MREMAP_MAYMOVE);

which I read as a "NOP".

Questions

(a) Will this actually do anything? Also, maybe it does now, but can't 
the kernel just optimize that out in the future?

(b) Is it even guaranteed that we can access > pagesize afterwards? I 
mean, we specify MREMAP_MAYMOVE.


I would suggest to just use mprotect/madvise to pte-map a PMD-THP.

This is, of course, independent of this patch.

-- 
Cheers

David / dhildenb



  parent reply	other threads:[~2025-09-01  7:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-31  2:27 [Patch v2] selftests/mm: check content to see whether mremap corrupt data Wei Yang
2025-09-01  2:08 ` wang lian
2025-09-01  7:22 ` David Hildenbrand [this message]
2025-09-01  8:11   ` wang lian
2025-09-01  8:16     ` David Hildenbrand
2025-09-01  8:34       ` wang lian
2025-09-01  8:43   ` Wei Yang
2025-09-01 12:56   ` Zi Yan
2025-09-01 13:03     ` David Hildenbrand
2025-09-01 17:04       ` Zi Yan
2025-09-01 19:10         ` David Hildenbrand
2025-09-02  2:51           ` Wei Yang
2025-09-02  7:49             ` David Hildenbrand
2025-09-02  8:13               ` Wei Yang
2025-09-02  8:23                 ` David Hildenbrand
2025-09-02  8:28                   ` Wei Yang
2025-09-02  8:16           ` Wei Yang
2025-09-02  8:26             ` David Hildenbrand
2025-09-02 14:56           ` Zi Yan
2025-09-02 15:28             ` David Hildenbrand
2025-09-02 15:39               ` Zi Yan
2025-09-02 15:40               ` David Hildenbrand
2025-09-02 15:42                 ` Zi Yan

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=f8e942de-1a50-412e-9020-1bc901b4243b@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=richard.weiyang@gmail.com \
    --cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).