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: <0575bcf6-c1a3-4ebf-a199-3113758fbdc5@arm.com>
Date: Thu, 18 Dec 2025 14:18:35 +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 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?

- Kevin