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: <7f0ac47d-1eff-4b79-b260-7812bf3ebc80@arm.com>
Date: Mon, 29 Dec 2025 12:46:45 +0100
From: Kevin Brodsky <kevin.brodsky@....com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>,
 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 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@....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.

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