The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another powerpc system, the same subtest failed because futex_wake() returned 0.
Bail out! futex2_wake(64, 0x86) should fail, but didn't
Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned.
Since this subtest is non-deterministic, it is dropped unless we explicitly set a guard page beyond the mmap region.
The other problematic test is the "Memory too small" test. The futex_wake() function returns the -EINVAL error code because the given futex address isn't 8-byte aligned, not because only 4 of the 8 bytes are valid and the other 4 bytes are not. So proper name of this subtest is changed to "Mis-aligned futex" to reflect the reality.
Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol") Signed-off-by: Waiman Long longman@redhat.com --- tools/testing/selftests/futex/functional/futex_numa_mpol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/futex/functional/futex_numa_mpol.c b/tools/testing/selftests/futex/functional/futex_numa_mpol.c index a9ecfb2d3932..802c15c82190 100644 --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c @@ -182,12 +182,10 @@ int main(int argc, char *argv[]) if (futex_numa->numa == FUTEX_NO_NODE) ksft_exit_fail_msg("NUMA node is left uninitialized\n");
- ksft_print_msg("Memory too small\n"); + /* FUTEX2_NUMA futex must be 8-byte aligned */ + ksft_print_msg("Mis-aligned futex\n"); test_futex(futex_ptr + mem_size - 4, 1);
- ksft_print_msg("Memory out of range\n"); - test_futex(futex_ptr + mem_size, 1); - futex_numa->numa = FUTEX_NO_NODE; mprotect(futex_ptr, mem_size, PROT_READ); ksft_print_msg("Memory, RO\n");
On 8/10/25 6:27 PM, Waiman Long wrote:
The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another powerpc system, the same subtest failed because futex_wake() returned 0.
Bail out! futex2_wake(64, 0x86) should fail, but didn't
Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned.
Since this subtest is non-deterministic, it is dropped unless we explicitly set a guard page beyond the mmap region.
The other problematic test is the "Memory too small" test. The futex_wake() function returns the -EINVAL error code because the given futex address isn't 8-byte aligned, not because only 4 of the 8 bytes are valid and the other 4 bytes are not. So proper name of this subtest is changed to "Mis-aligned futex" to reflect the reality.
Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol") Signed-off-by: Waiman Long longman@redhat.com
Ping! Any comment or suggested change?
-Longman
tools/testing/selftests/futex/functional/futex_numa_mpol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/futex/functional/futex_numa_mpol.c b/tools/testing/selftests/futex/functional/futex_numa_mpol.c index a9ecfb2d3932..802c15c82190 100644 --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c @@ -182,12 +182,10 @@ int main(int argc, char *argv[]) if (futex_numa->numa == FUTEX_NO_NODE) ksft_exit_fail_msg("NUMA node is left uninitialized\n");
- ksft_print_msg("Memory too small\n");
- /* FUTEX2_NUMA futex must be 8-byte aligned */
- ksft_print_msg("Mis-aligned futex\n"); test_futex(futex_ptr + mem_size - 4, 1);
- ksft_print_msg("Memory out of range\n");
- test_futex(futex_ptr + mem_size, 1);
- futex_numa->numa = FUTEX_NO_NODE; mprotect(futex_ptr, mem_size, PROT_READ); ksft_print_msg("Memory, RO\n");
On 2025-08-10 18:27:42 [-0400], Waiman Long wrote:
The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another powerpc system, the same subtest failed because futex_wake() returned 0.
Bail out! futex2_wake(64, 0x86) should fail, but didn't
Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned.
Since this subtest is non-deterministic, it is dropped unless we explicitly set a guard page beyond the mmap region.
The other problematic test is the "Memory too small" test. The futex_wake() function returns the -EINVAL error code because the given futex address isn't 8-byte aligned, not because only 4 of the 8 bytes are valid and the other 4 bytes are not. So proper name of this subtest is changed to "Mis-aligned futex" to reflect the reality.
Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol") Signed-off-by: Waiman Long longman@redhat.com
This makes sense. Reviewed-by: Sebastian Andrzej Siewior bigeasy@linutronix.de
Sebastian
Hi Waiman,
Em 10/08/2025 19:27, Waiman Long escreveu:
The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another powerpc system, the same subtest failed because futex_wake() returned 0.
Bail out! futex2_wake(64, 0x86) should fail, but didn't
Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned.
Since this subtest is non-deterministic, it is dropped unless we explicitly set a guard page beyond the mmap region.
I had proposed a refactor of the futex selftests[1] and I spotted the same issue with the memory out of range test. My solution for this was to create a "buffer zone" with PROT_NONE to ensure that I would have a invalid memory access:
/* * test_harness_run() calls mmap(..., MAP_SHARED, ...), which can create * a valid access memory region just bellow the mmap() issue here. Then, * the test for "Memory out of range" will fail because it will succeed * accessing the memory address after the range. To avoid this we create * a "Buffer zone" with PROT_NONE between the two mmap's. */ buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
[1] https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13-c0ff4f...
On 8/19/25 8:22 AM, André Almeida wrote:
Hi Waiman,
Em 10/08/2025 19:27, Waiman Long escreveu:
The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another powerpc system, the same subtest failed because futex_wake() returned 0.
Bail out! futex2_wake(64, 0x86) should fail, but didn't
Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned.
Since this subtest is non-deterministic, it is dropped unless we explicitly set a guard page beyond the mmap region.
I had proposed a refactor of the futex selftests[1] and I spotted the same issue with the memory out of range test. My solution for this was to create a "buffer zone" with PROT_NONE to ensure that I would have a invalid memory access:
/* * test_harness_run() calls mmap(..., MAP_SHARED, ...), which can create * a valid access memory region just bellow the mmap() issue here. Then, * the test for "Memory out of range" will fail because it will succeed * accessing the memory address after the range. To avoid this we create * a "Buffer zone" with PROT_NONE between the two mmap's. */ buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
[1] https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13-c0ff4f...
That should work too.
I am fine with either my patch or your getting merged as it should address the test failure that I had encountered.
Cheers, Longman
linux-kselftest-mirror@lists.linaro.org
-
André Almeida -
Sebastian Andrzej Siewior -
Waiman Long -
Waiman Long