linux-stable.git/tools/testing/selftests/futex, branch linux-6.17.y

selftest/futex: Compile also with libnuma < 2.0.16

2025-10-15T10:03:35+00:00

[ Upstream commit ed323aeda5e09fa1ab95946673939c8c425c329c ]

After using numa_set_mempolicy_home_node() the test fails to compile on
systems with libnuma library versioned lower than 2.0.16.

In order to allow lower library version add a pkg-config related check
and exclude that part of the code. Without the proper MPOL setup it
can't be tested.

Make a total number of tests two. The first one is the first batch and
the second is the MPOL related one. The goal is to let the user know if
it has been skipped due to library limitation.

Remove test_futex_mpol(), it was unused and it is now complained by the
compiler if the part is not compiled.

Fixes: 0ecb4232fc65e ("selftests/futex: Set the home_node in futex_numa_mpol")
Closes: https://lore.kernel.org/oe-lkp/202507150858.bedaf012-lkp@intel.com
Reported-by: kernel test robot 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Sasha Levin

selftest/futex: Make the error check more precise for futex_numa_mpol

2025-10-15T10:03:35+00:00

[ Upstream commit c1c863457780adfb2e29fa9a85897179ad3903e6 ]

Instead of just checking if the syscall failed as expected, check as
well if the returned error code matches the expected error code.

[ bigeasy: reword the commmit message ]

Signed-off-by: André Almeida 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Waiman Long 
Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16")
Signed-off-by: Sasha Levin

selftests/futex: Fix futex_wait() for 32bit ARM

2025-10-15T10:03:34+00:00

[ Upstream commit 237bfb76c90b184f57bb18fe35ff366c19393dc8 ]

On 32bit ARM systems gcc-12 will use 32bit timestamps while gcc-13 and later
will use 64bit timestamps.  The problem is that SYS_futex will continue
pointing at the 32bit system call.  This makes the futex_wait test fail like
this:

  waiter failed errno 110
  not ok 1 futex_wake private returned: 0 Success
  waiter failed errno 110
  not ok 2 futex_wake shared (page anon) returned: 0 Success
  waiter failed errno 110
  not ok 3 futex_wake shared (file backed) returned: 0 Success

Instead of compiling differently depending on the gcc version, use the
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 options to ensure that 64bit timestamps
are used.  Then use ifdefs to make SYS_futex point to the 64bit system call.

Signed-off-by: Dan Carpenter 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: André Almeida 
Tested-by: Anders Roxell 
Link: https://lore.kernel.org/20250827130011.677600-6-bigeasy@linutronix.de
Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16")
Signed-off-by: Sasha Levin

selftests/futex: Fix some futex_numa_mpol subtests

2025-10-15T10:03:23+00:00

[ Upstream commit d8e2f919997b14665e4509ef9a5278f291598d6e ]

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, drop it unless a guard page beyond
the mmap region is explicitly set.

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 change the name of this subtest to "Mis-aligned futex" to
reflect the reality.

  [ bp: Massage commit message. ]

Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
Signed-off-by: Waiman Long 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Sebastian Andrzej Siewior 
Link: https://lore.kernel.org/20250827130011.677600-3-bigeasy@linutronix.de
Signed-off-by: Sasha Levin

selftests/futex: Remove the -g parameter from futex_priv_hash

2025-10-15T10:03:22+00:00

[ Upstream commit 2e62688d583809e832433f461194334408b10817 ]

The -g parameter was meant to the test the immutable global hash instead of the
private hash which has been made immutable. The global hash is tested as part
at the end of the regular test. The immutable private hash been removed.

Remove last traces of the immutable private hash.

Fixes: 16adc7f136dc1 ("selftests/futex: Remove support for IMMUTABLE")
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: André Almeida 
Link: https://lore.kernel.org/20250827130011.677600-2-bigeasy@linutronix.de
Signed-off-by: Sasha Levin

Merge tag 'locking-futex-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-07-29T21:39:42+00:00

Pull futex updates from Thomas Gleixner:

 - Switch the reference counting to a RCU based per-CPU reference to
   address a performance bottleneck vs the single instance rcuref
   variant

 - Make the futex selftest build on 32-bit architectures which only
   support 64-bit time_t, e.g. RISCV-32

 - Cleanups and improvements in selftests and futex bench

* tag 'locking-futex-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  selftests/futex: Fix spelling mistake "Succeffuly" -> "Successfully"
  selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit time_t
  perf bench futex: Remove support for IMMUTABLE
  selftests/futex: Remove support for IMMUTABLE
  futex: Remove support for IMMUTABLE
  futex: Make futex_private_hash_get() static
  futex: Use RCU-based per-CPU reference counting instead of rcuref_t
  selftests/futex: Adapt the private hash test to RCU related changes

selftests/futex: Fix spelling mistake "Succeffuly" -> "Successfully"

2025-07-22T09:18:43+00:00

There is a spelling mistake in a ksft_exit_fail_msg() message. Fix it.

Signed-off-by: Colin Ian King 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20250715130627.1907017-1-colin.i.king@gmail.com

selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit time_t

2025-07-22T09:18:43+00:00

The kernel does not provide sys_futex() on 32-bit architectures that do not
support 32-bit time representations, such as riscv32.

As a result, glibc cannot define SYS_futex, causing compilation failures in
tests that rely on this syscall. Define SYS_futex as SYS_futex_time64 in
such cases to ensure successful compilation and compatibility.

Signed-off-by: Cynthia Huang 
Signed-off-by: Ben Zong-You Xie 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Muhammad Usama Anjum 
Link: https://lore.kernel.org/all/20250710103630.3156130-1-ben717@andestech.com

selftests/futex: Remove support for IMMUTABLE

2025-07-11T14:02:01+00:00

Testing for the IMMUTABLE part of the futex interface is not needed
after the removal of the interface.

Remove support for IMMUTABLE from the sefltest.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20250710110011.384614-6-bigeasy@linutronix.de

selftests/futex: Adapt the private hash test to RCU related changes

2025-07-11T14:02:00+00:00

The auto scaling on create creation used to automatically assign the new
hash because there was the private hash was unused and could be replaced
right away.

This is already racy because if the private hash is in use by a thread
then the visibile resize will be delayed. With the upcoming change to
wait for a RCU grace period before the hash can be assigned, the test
will always fail.

If the reported number of hash buckets is not updated after an
auto scaling event, block on an acquired lock with a timeout. The timeout
is the delay to wait towards a grace period and locking and a locked
pthread_mutex_t ensure that glibc calls into kernel using futex
operation which will assign new private hash if available.
This will retry every 100ms up to 2 seconds in total.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20250710110011.384614-2-bigeasy@linutronix.de