* [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
@ 2025-08-27 15:44 André Almeida
2025-08-27 17:58 ` Waiman Long
0 siblings, 1 reply; 11+ messages in thread
From: André Almeida @ 2025-08-27 15:44 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-kernel
Cc: Darren Hart, Davidlohr Bueso, Ingo Molnar, Juri Lelli,
Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, Waiman Long, kernel-dev, André Almeida
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-27 15:44 [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest André Almeida
@ 2025-08-27 17:58 ` Waiman Long
2025-08-28 6:32 ` Sebastian Andrzej Siewior
2025-08-28 18:06 ` André Almeida
0 siblings, 2 replies; 11+ messages in thread
From: Waiman Long @ 2025-08-27 17:58 UTC (permalink / raw)
To: André Almeida, Sebastian Andrzej Siewior, linux-kernel
Cc: Darren Hart, Davidlohr Bueso, Ingo Molnar, Juri Lelli,
Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev
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;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-27 17:58 ` Waiman Long
@ 2025-08-28 6:32 ` Sebastian Andrzej Siewior
2025-08-28 18:06 ` André Almeida
1 sibling, 0 replies; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-08-28 6:32 UTC (permalink / raw)
To: Waiman Long
Cc: André Almeida, linux-kernel, Darren Hart, Davidlohr Bueso,
Ingo Molnar, Juri Lelli, Peter Zijlstra, Thomas Gleixner,
Valentin Schneider, Borislav Petkov, kernel-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-27 17:58 ` Waiman Long
2025-08-28 6:32 ` Sebastian Andrzej Siewior
@ 2025-08-28 18:06 ` André Almeida
2025-08-28 18:20 ` Sebastian Andrzej Siewior
1 sibling, 1 reply; 11+ messages in thread
From: André Almeida @ 2025-08-28 18:06 UTC (permalink / raw)
To: Waiman Long, Sebastian Andrzej Siewior
Cc: Darren Hart, Davidlohr Bueso, Ingo Molnar, Juri Lelli,
Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev, linux-kernel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-28 18:06 ` André Almeida
@ 2025-08-28 18:20 ` Sebastian Andrzej Siewior
2025-08-28 18:47 ` Waiman Long
2025-08-29 2:22 ` André Almeida
0 siblings, 2 replies; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-08-28 18:20 UTC (permalink / raw)
To: André Almeida
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-28 18:20 ` Sebastian Andrzej Siewior
@ 2025-08-28 18:47 ` Waiman Long
2025-08-29 2:22 ` André Almeida
1 sibling, 0 replies; 11+ messages in thread
From: Waiman Long @ 2025-08-28 18:47 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, André Almeida
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-28 18:20 ` Sebastian Andrzej Siewior
2025-08-28 18:47 ` Waiman Long
@ 2025-08-29 2:22 ` André Almeida
2025-08-29 6:16 ` Sebastian Andrzej Siewior
1 sibling, 1 reply; 11+ messages in thread
From: André Almeida @ 2025-08-29 2:22 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev, linux-kernel
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-29 2:22 ` André Almeida
@ 2025-08-29 6:16 ` Sebastian Andrzej Siewior
2025-08-29 10:07 ` Borislav Petkov
0 siblings, 1 reply; 11+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-08-29 6:16 UTC (permalink / raw)
To: André Almeida
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
Borislav Petkov, kernel-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-29 6:16 ` Sebastian Andrzej Siewior
@ 2025-08-29 10:07 ` Borislav Petkov
2025-09-01 12:49 ` André Almeida
0 siblings, 1 reply; 11+ messages in thread
From: Borislav Petkov @ 2025-08-29 10:07 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, André Almeida
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
kernel-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-08-29 10:07 ` Borislav Petkov
@ 2025-09-01 12:49 ` André Almeida
2025-09-01 13:57 ` Borislav Petkov
0 siblings, 1 reply; 11+ messages in thread
From: André Almeida @ 2025-09-01 12:49 UTC (permalink / raw)
To: Borislav Petkov, Sebastian Andrzej Siewior
Cc: Waiman Long, Darren Hart, Davidlohr Bueso, Ingo Molnar,
Juri Lelli, Peter Zijlstra, Thomas Gleixner, Valentin Schneider,
kernel-dev, linux-kernel
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 :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest
2025-09-01 12:49 ` André Almeida
@ 2025-09-01 13:57 ` Borislav Petkov
0 siblings, 0 replies; 11+ messages in thread
From: Borislav Petkov @ 2025-09-01 13:57 UTC (permalink / raw)
To: André Almeida
Cc: Sebastian Andrzej Siewior, Waiman Long, Darren Hart,
Davidlohr Bueso, Ingo Molnar, Juri Lelli, Peter Zijlstra,
Thomas Gleixner, Valentin Schneider, kernel-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-09-01 13:57 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-27 15:44 [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of range subtest André Almeida
2025-08-27 17:58 ` Waiman Long
2025-08-28 6:32 ` Sebastian Andrzej Siewior
2025-08-28 18:06 ` André Almeida
2025-08-28 18:20 ` Sebastian Andrzej Siewior
2025-08-28 18:47 ` Waiman Long
2025-08-29 2:22 ` André Almeida
2025-08-29 6:16 ` Sebastian Andrzej Siewior
2025-08-29 10:07 ` Borislav Petkov
2025-09-01 12:49 ` André Almeida
2025-09-01 13:57 ` Borislav Petkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).