There are timing issues in the use of threads in some selftests for futexes
as the tests rely on timed waits to ensure that the other test thread[s]
reached the lock wait function in the kernel.

That "works" on halfways idle systems, but fails under load which results
in tests failing.

Provide a set of helper functions to create test threads and to wait for
them to reach the lock wait by monitoring /proc/$PID/wchan.

[ tglx: Fixup coding style, move the timeout into the helper, adapt to test
  	harness changes and massage change log ]

Signed-off-by: Yuwen Chen <ywen.chen@foxmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/tencent_4C90BE98BBC48B38B9FBC6A95C45CF49F309@qq.com

The futex functional tests cover FUTEX_LOCK_PI timeout semantics
(futex_wait_timeout.c) and robust-list owner death (robust_list.c), but
nothing exercises a non-robust PI owner exiting while holding the lock,
nor the basic ownership / EDEADLK / unlock word semantics of
FUTEX_LOCK_PI.

Add futex_lock_pi_exiting.c with three tests:

 - lock_unlock_basic: an uncontended FUTEX_LOCK_PI puts the owner TID in
   the futex word, a recursive lock by the owner returns EDEADLK, and
   FUTEX_UNLOCK_PI clears the word.

 - owner_dies_with_blocked_waiter: a thread acquires a PI futex and exits
   while holding it; a blocked FUTEX_LOCK_PI waiter must come out cleanly
   (0, EOWNERDEAD or ESRCH) and own the lock when it acquires.

 - stress_owner_exits: repeatedly drive the same exiting-owner path.

The exiting-owner retry path is where commit 210d36d892de ("futex: Clear
stale exiting pointer in futex_lock_pi() retry path") fixed a stale task
pointer that tripped WARN_ON_ONCE() in wait_for_owner_exiting(). That
warning does not change the syscall return value, so this test does not
assert on it directly; the stress loop exists to give a kernel booted
with panic_on_warn=1 (as fuzzers and CI commonly run) a chance to trip
on it.

Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260607183249.246037-1-vebohr@gmail.com

numa_set_mempolicy_home_node() was introduced in libnuma 2.0.18, not
2.0.16, via:
	https://github.com/numactl/numactl/commit/8f2ffc89654c

Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/20260306182215.2088991-1-dave@stgolabs.net

Use LIBNUMA_TEST to conditionally add -lnuma to LDLIBS.
Guard numa header includes with #ifdef LIBNUMA_VER_SUFFICIENT
to allow compilation without libnuma installed.

Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260301-20260128_nylon_chen_sifive_com-v3-1-995ab4cc71aa@sifive.com

Create a test for the robust list mechanism. Test the following uAPI
operations:

- Creating a robust mutex where the lock waiter is wake by the kernel
  when the lock owner died
- Setting a robust list to the current task
- Getting a robust list from the current task
- Getting a robust list from another task
- Using the list_op_pending field from robust_list_head struct to test
  robustness when the lock owner dies before completing the locking
- Setting a invalid size for syscall argument `len`
- Adding multiple elements to a robust list wait waiting for each of
  them
- Creating a circular list and checking that the kernel does not get
  stuck in an infinity loop

Signed-off-by: André Almeida <andrealmeid@igalia.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://patch.msgid.link/20251110224130.3044761-1-andrealmeid@igalia.com

Every futex selftest uses the kselftest_harness.h helper and don't need
the logging.h file. Delete it.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

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 <oliver.sang@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

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 <dan.carpenter@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: André Almeida <andrealmeid@igalia.com>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Link: https://lore.kernel.org/20250827130011.677600-6-bigeasy@linutronix.de

Implement a simple NUMA aware spinlock for testing and howto purposes.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Test the basic functionality for the NUMA and MPOL flags:
- FUTEX2_NUMA should take the NUMA node which is after the uaddr
  and use it.
- Only update the node if FUTEX_NO_NODE was set by the user
- FUTEX2_MPOL should use the memory based on the policy. I attempted to
  set the node with mbind() and then use this with MPOL but this fails
  and futex falls back to the default node for the current CPU.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250416162921.513656-22-bigeasy@linutronix.de