linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Brodsky <kevin.brodsky@arm.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Mark Brown <broonie@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Usama Anjum <Usama.Anjum@arm.com>
Subject: Re: [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap_ioctl test
Date: Mon, 29 Dec 2025 12:46:45 +0100	[thread overview]
Message-ID: <7f0ac47d-1eff-4b79-b260-7812bf3ebc80@arm.com> (raw)
In-Reply-To: <a3ca6293-8f85-4489-a48e-eb8d0d3792c5@kernel.org>

On 19/12/2025 09:29, David Hildenbrand (Red Hat) wrote:
> On 12/18/25 14:18, Kevin Brodsky wrote:
>> On 18/12/2025 09:05, David Hildenbrand (Red Hat) wrote:
>>> On 12/16/25 15:56, Ryan Roberts wrote:
>>>> On 16/12/2025 14:26, Kevin Brodsky wrote:
>>>>> One of the pagemap_ioctl tests attempts to fault in pages by
>>>>> memcpy()'ing them to an unused buffer. This probably worked
>>>>> originally, but since commit 46036188ea1f ("selftests/mm: build with
>>>>> -O2") the compiler is free to optimise away that unused buffer and
>>>>> the memcpy() with it. As a result there might not be any resident
>>>>> page in the mapping and the test may fail.
>>>>>
>>>>> We don't need to copy all that memory anyway. Just fault in every
>>>>> page by forcing the compiler to read the first byte.
>>>>>
>>>>> Cc: Usama Anjum <Usama.Anjum@arm.com>
>>>>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>>>>> ---
>>>>>    tools/testing/selftests/mm/pagemap_ioctl.c | 6 +++---
>>>>>    1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/tools/testing/selftests/mm/pagemap_ioctl.c
>>>>> b/tools/testing/selftests/mm/pagemap_ioctl.c
>>>>> index 2cb5441f29c7..67a7a3705604 100644
>>>>> --- a/tools/testing/selftests/mm/pagemap_ioctl.c
>>>>> +++ b/tools/testing/selftests/mm/pagemap_ioctl.c
>>>>> @@ -1056,7 +1056,6 @@ int sanity_tests(void)
>>>>>        struct page_region *vec;
>>>>>        char *mem, *fmem;
>>>>>        struct stat sbuf;
>>>>> -    char *tmp_buf;
>>>>>          /* 1. wrong operation */
>>>>>        mem_size = 10 * page_size;
>>>>> @@ -1167,8 +1166,9 @@ int sanity_tests(void)
>>>>>        if (fmem == MAP_FAILED)
>>>>>            ksft_exit_fail_msg("error nomem %d %s\n", errno,
>>>>> strerror(errno));
>>>>>    -    tmp_buf = malloc(sbuf.st_size);
>>>>> -    memcpy(tmp_buf, fmem, sbuf.st_size);
>>>>> +    /* Fault in every page by reading the first byte */
>>>>> +    for (i = 0; i < sbuf.st_size; i += page_size)
>>>>> +        (void)*(volatile char *)(fmem + i);
>>>>
>>>> We have FORCE_READ() in vm_util.h for this. Perhaps that would be
>>>> better?
>>>
>>> Agreed, and if we have multiple patterns where we want to force_read a
>>> bigger area, maybe we should provide a helper for that?
>>
>> I've found just a couple of cases where FORCE_READ() is used for a
>> larger area (in hugetlb-madvise.c and split_huge_page_test.c). The step
>> size isn't the same in any of these cases though. We could have
>> something like fault_area(addr, size, step) but maybe the loops are
>> clear enough already?
>
> Note that even for hugtlb we can read page-per-page, no need to
> hugetlb-page-per-hugetlb-page. Not sure if the performance change
> would make any real performance difference in this testing code.

Fair point. In fact in split_huge_page_test.c we're reading every byte
but that's unnecessary. I'll add a helper that reads page-by-page and
use that in all 3 cases.

- Kevin


  reply	other threads:[~2025-12-29 11:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16 14:26 [PATCH 0/4] Various mm kselftests improvements/fixes Kevin Brodsky
2025-12-16 14:26 ` [PATCH 1/4] selftests/mm: remove flaky header check Kevin Brodsky
2025-12-17  3:18   ` Yunsheng Lin
2025-12-17  9:58     ` Kevin Brodsky
2025-12-18  7:21       ` Yunsheng Lin
2025-12-17 10:04   ` Mark Brown
2025-12-18 13:24     ` Kevin Brodsky
2025-12-18 14:25       ` Mark Brown
2025-12-29 15:40         ` Kevin Brodsky
2025-12-16 14:26 ` [PATCH 2/4] selftests/mm: pass down full CC and CFLAGS to check_config.sh Kevin Brodsky
2025-12-18  8:04   ` David Hildenbrand (Red Hat)
2025-12-16 14:26 ` [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap_ioctl test Kevin Brodsky
2025-12-16 14:56   ` Ryan Roberts
2025-12-16 15:11     ` Kevin Brodsky
2025-12-18  8:05     ` David Hildenbrand (Red Hat)
2025-12-18 13:18       ` Kevin Brodsky
2025-12-19  8:29         ` David Hildenbrand (Red Hat)
2025-12-29 11:46           ` Kevin Brodsky [this message]
2025-12-16 14:26 ` [PATCH 4/4] selftests/mm: fix exit code in pagemap_ioctl Kevin Brodsky
2025-12-16 14:58   ` Ryan Roberts
2025-12-17 10:08   ` Mark Brown
2025-12-18 13:20     ` Kevin Brodsky
2025-12-18  8:07   ` David Hildenbrand (Red Hat)

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=7f0ac47d-1eff-4b79-b260-7812bf3ebc80@arm.com \
    --to=kevin.brodsky@arm.com \
    --cc=Usama.Anjum@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@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