The "Memory out of range" subtest works by pointing the futex pointer
to the memory exactly after the allocated map (futex_ptr + mem_size).
This address is out of the allocated range for futex_ptr, but depending
on the memory layout, it might be pointing to a valid memory address of
the process. In order to make this test deterministic, create a "buffer
zone" with PROT_NONE just before allocating the valid futex_ptr memory,
to make sure that futex_ptr + mem_size falls into a memory address that
will return an invalid access error.

Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
This patch comes from this series:
https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13-c0ff4f24c4e1@igalia.com/
---
 .../futex/functional/futex_numa_mpol.c          | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/futex/functional/futex_numa_mpol.c b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
index a9ecfb2d3932..1eb3e67d999b 100644
--- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c
+++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
@@ -143,7 +143,7 @@ int main(int argc, char *argv[])
 {
 	struct futex32_numa *futex_numa;
 	int mem_size, i;
-	void *futex_ptr;
+	void *futex_ptr, *buffer_zone;
 	int c;
 
 	while ((c = getopt(argc, argv, "chv:")) != -1) {
@@ -168,6 +168,17 @@ int main(int argc, char *argv[])
 	ksft_set_plan(1);
 
 	mem_size = sysconf(_SC_PAGE_SIZE);
+
+	/*
+	 * The "Memory out of range" test depends on having a pointer to an
+	 * invalid address. To make this test deterministic, and to not depend
+	 * on the memory layout of the process, create a "buffer zone" with
+	 * PROT_NONE just before the valid memory (*futex_ptr).
+	 */
+	buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+	if (buffer_zone == MAP_FAILED)
+		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
+
 	futex_ptr = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
 	if (futex_ptr == MAP_FAILED)
 		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
@@ -229,6 +240,10 @@ int main(int argc, char *argv[])
 			}
 		}
 	}
+
+	munmap(buffer_zone, mem_size);
+	munmap(futex_ptr, mem_size);
+
 	ksft_test_result_pass("NUMA MPOL tests passed\n");
 	ksft_finished();
 	return 0;
-- 
2.50.1

On 8/27/25 11:44 AM, André Almeida wrote:
> The "Memory out of range" subtest works by pointing the futex pointer
> to the memory exactly after the allocated map (futex_ptr + mem_size).
> This address is out of the allocated range for futex_ptr, but depending
> on the memory layout, it might be pointing to a valid memory address of
> the process. In order to make this test deterministic, create a "buffer
> zone" with PROT_NONE just before allocating the valid futex_ptr memory,
> to make sure that futex_ptr + mem_size falls into a memory address that
> will return an invalid access error.
>
> Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> This patch comes from this series:
> https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13-c0ff4f24c4e1@igalia.com/
> ---
>   .../futex/functional/futex_numa_mpol.c          | 17 ++++++++++++++++-
>   1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/futex/functional/futex_numa_mpol.c b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
> index a9ecfb2d3932..1eb3e67d999b 100644
> --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c
> +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
> @@ -143,7 +143,7 @@ int main(int argc, char *argv[])
>   {
>   	struct futex32_numa *futex_numa;
>   	int mem_size, i;
> -	void *futex_ptr;
> +	void *futex_ptr, *buffer_zone;
>   	int c;
>   
>   	while ((c = getopt(argc, argv, "chv:")) != -1) {
> @@ -168,6 +168,17 @@ int main(int argc, char *argv[])
>   	ksft_set_plan(1);
>   
>   	mem_size = sysconf(_SC_PAGE_SIZE);
> +
> +	/*
> +	 * The "Memory out of range" test depends on having a pointer to an
> +	 * invalid address. To make this test deterministic, and to not depend
> +	 * on the memory layout of the process, create a "buffer zone" with
> +	 * PROT_NONE just before the valid memory (*futex_ptr).
> +	 */
> +	buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> +	if (buffer_zone == MAP_FAILED)
> +		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
> +
>   	futex_ptr = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
>   	if (futex_ptr == MAP_FAILED)
>   		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);

This patch makes the assumption that consecutive mmap() calls will 
allocate pages consecutively downward from a certain address. I don't 
know if this assumption will be valid in all cases. I think it will be 
safer to just allocate the 2-page memory block and then change the 2nd 
page protection to PROT_NONE to make it a guard page.

Cheers,
Longman

> @@ -229,6 +240,10 @@ int main(int argc, char *argv[])
>   			}
>   		}
>   	}
> +
> +	munmap(buffer_zone, mem_size);
> +	munmap(futex_ptr, mem_size);
> +
>   	ksft_test_result_pass("NUMA MPOL tests passed\n");
>   	ksft_finished();
>   	return 0;

Em 27/08/2025 14:58, Waiman Long escreveu:
> 
> On 8/27/25 11:44 AM, André Almeida wrote:
>> The "Memory out of range" subtest works by pointing the futex pointer
>> to the memory exactly after the allocated map (futex_ptr + mem_size).
>> This address is out of the allocated range for futex_ptr, but depending
>> on the memory layout, it might be pointing to a valid memory address of
>> the process. In order to make this test deterministic, create a "buffer
>> zone" with PROT_NONE just before allocating the valid futex_ptr memory,
>> to make sure that futex_ptr + mem_size falls into a memory address that
>> will return an invalid access error.
>>
>> Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>> This patch comes from this series:
>> https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13- 
>> c0ff4f24c4e1@igalia.com/
>> ---
>>   .../futex/functional/futex_numa_mpol.c          | 17 ++++++++++++++++-
>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/futex/functional/ 
>> futex_numa_mpol.c b/tools/testing/selftests/futex/functional/ 
>> futex_numa_mpol.c
>> index a9ecfb2d3932..1eb3e67d999b 100644
>> --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c
>> +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
>> @@ -143,7 +143,7 @@ int main(int argc, char *argv[])
>>   {
>>       struct futex32_numa *futex_numa;
>>       int mem_size, i;
>> -    void *futex_ptr;
>> +    void *futex_ptr, *buffer_zone;
>>       int c;
>>       while ((c = getopt(argc, argv, "chv:")) != -1) {
>> @@ -168,6 +168,17 @@ int main(int argc, char *argv[])
>>       ksft_set_plan(1);
>>       mem_size = sysconf(_SC_PAGE_SIZE);
>> +
>> +    /*
>> +     * The "Memory out of range" test depends on having a pointer to an
>> +     * invalid address. To make this test deterministic, and to not 
>> depend
>> +     * on the memory layout of the process, create a "buffer zone" with
>> +     * PROT_NONE just before the valid memory (*futex_ptr).
>> +     */
>> +    buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | 
>> MAP_ANONYMOUS, 0, 0);
>> +    if (buffer_zone == MAP_FAILED)
>> +        ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
>> +
>>       futex_ptr = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, 
>> MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
>>       if (futex_ptr == MAP_FAILED)
>>           ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
> 
> This patch makes the assumption that consecutive mmap() calls will 
> allocate pages consecutively downward from a certain address. I don't 
> know if this assumption will be valid in all cases. I think it will be 
> safer to just allocate the 2-page memory block and then change the 2nd 
> page protection to PROT_NONE to make it a guard page.
> 

Thanks for the feedback! I will send a v2 addressing this by next week.

On 2025-08-28 15:06:26 [-0300], André Almeida wrote:
> Thanks for the feedback! I will send a v2 addressing this by next week.

Any objections for getting Waiman's fix in for now and your rework for
next merge window?

Sebastian

Em 28/08/2025 15:20, Sebastian Andrzej Siewior escreveu:
> On 2025-08-28 15:06:26 [-0300], André Almeida wrote:
>> Thanks for the feedback! I will send a v2 addressing this by next week.
> 
> Any objections for getting Waiman's fix in for now and your rework for
> next merge window?
> 

No objections merging Waiman fix first, but we are still in -rc3, so 
maybe there's time for the rework in this cycle?

On 2025-08-28 23:22:03 [-0300], André Almeida wrote:
> Em 28/08/2025 15:20, Sebastian Andrzej Siewior escreveu:
> > On 2025-08-28 15:06:26 [-0300], André Almeida wrote:
> > > Thanks for the feedback! I will send a v2 addressing this by next week.
> > 
> > Any objections for getting Waiman's fix in for now and your rework for
> > next merge window?
> > 
> 
> No objections merging Waiman fix first, but we are still in -rc3, so maybe
> there's time for the rework in this cycle?

On the regression list, we this one fallout in the testsuite. I would
like to get an easy fix for -rc4 and be done with it for this cycle. 

Sebastian

On Fri, Aug 29, 2025 at 08:16:24AM +0200, Sebastian Andrzej Siewior wrote:
> > No objections merging Waiman fix first, but we are still in -rc3, so maybe
> > there's time for the rework in this cycle?

... and you can rework all you want. When your solution is ready and everyone
agrees, there's nothing wrong with queueing it ontop or delaying it for the
next merge window.

> On the regression list, we this one fallout in the testsuite. I would
> like to get an easy fix for -rc4 and be done with it for this cycle. 

There's absolutely no place for hurrying things, especially for self tests. So
take your time pls.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Em 29/08/2025 07:07, Borislav Petkov escreveu:
> On Fri, Aug 29, 2025 at 08:16:24AM +0200, Sebastian Andrzej Siewior wrote:
>>> No objections merging Waiman fix first, but we are still in -rc3, so maybe
>>> there's time for the rework in this cycle?
> 
> ... and you can rework all you want. When your solution is ready and everyone
> agrees, there's nothing wrong with queueing it ontop or delaying it for the
> next merge window.
> 
>> On the regression list, we this one fallout in the testsuite. I would
>> like to get an easy fix for -rc4 and be done with it for this cycle.
> 
> There's absolutely no place for hurrying things, especially for self tests. So
> take your time pls.
> 

Sure, I don't want to hurry things, I'm just trying to understand better 
the rationale of having this for the next cycle, and if I would have to 
wait or not till the next kernel release to send the patch :)

On Mon, Sep 01, 2025 at 09:49:14AM -0300, André Almeida wrote:
> Sure, I don't want to hurry things, I'm just trying to understand better the
> rationale of having this for the next cycle, and if I would have to wait or
> not till the next kernel release to send the patch :)

You don't have to wait for any release - you just send it out when it is ready
and the maintainers decide.

If you want to specify something about the patch, you can put your note under
the "---" line and that's it.

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 8/28/25 2:20 PM, Sebastian Andrzej Siewior wrote:
> On 2025-08-28 15:06:26 [-0300], André Almeida wrote:
>> Thanks for the feedback! I will send a v2 addressing this by next week.
> Any objections for getting Waiman's fix in for now and your rework for
> next merge window?

I would prefer this as well. Thanks!

Cheers,
Longman

On 2025-08-27 13:58:50 [-0400], Waiman Long wrote:
> On 8/27/25 11:44 AM, André Almeida wrote:
> > --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c
> > +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
> > @@ -168,6 +168,17 @@ int main(int argc, char *argv[])
> >   	ksft_set_plan(1);
> >   	mem_size = sysconf(_SC_PAGE_SIZE);
> > +
> > +	/*
> > +	 * The "Memory out of range" test depends on having a pointer to an
> > +	 * invalid address. To make this test deterministic, and to not depend
> > +	 * on the memory layout of the process, create a "buffer zone" with
> > +	 * PROT_NONE just before the valid memory (*futex_ptr).
> > +	 */
> > +	buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> > +	if (buffer_zone == MAP_FAILED)
> > +		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
> > +
> >   	futex_ptr = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> >   	if (futex_ptr == MAP_FAILED)
> >   		ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
> 
> This patch makes the assumption that consecutive mmap() calls will allocate
> pages consecutively downward from a certain address. I don't know if this
> assumption will be valid in all cases. I think it will be safer to just
> allocate the 2-page memory block and then change the 2nd page protection to
> PROT_NONE to make it a guard page.

You shouldn't make any assumption about mmap()'s returned pointer unless
you pass it as the addr argument and expect it to be followed.
Using two pages and making the second a guard page sounds sane.

> Cheers,
> Longman

Sebastian