Re: [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap_ioctl test

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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.

-- 
Cheers

David