linux-kernel - Re: [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3ca6293-8f85-4489-a48e-eb8d0d3792c5@kernel.org>
Date: Fri, 19 Dec 2025 09:29:06 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Kevin Brodsky <kevin.brodsky@....com>, Ryan Roberts
 <ryan.roberts@....com>, linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Mark Brown
 <broonie@...nel.org>, Shuah Khan <shuah@...nel.org>,
 Usama Anjum <Usama.Anjum@....com>
Subject: Re: [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap_ioctl
 test

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@....com>
>>>> Signed-off-by: Kevin Brodsky <kevin.brodsky@....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