The pid_max kselftest hardcodes pid_max values of 400 and 500, but the
kernel enforces a minimum of PIDS_PER_CPU_MIN * num_possible_cpus().
On machines with many possible CPUs (e.g. nr_cpu_ids=128 yields a
minimum of 1024), writing 400 or 500 to /proc/sys/kernel/pid_max
returns EINVAL and all three tests fail.
Compute these limits the same way as the kernel does and set outer_limit
and inner_limit dynamically based on the result. Original test semantics
are preserved (outer < inner, nested namespace capped by parent).
Signed-off-by: Bjoern Doebel <doebel@amazon.com>
Link: https://patch.msgid.link/20260422201151.3830506-1-doebel@amazon.com
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Assisted-by: Kiro:claude-opus-4.6
Signed-off-by: Christian Brauner <brauner@kernel.org>
First testcase "pidns_init_via_setns" checks that a process can become
Pid 1 (init) in a new Pid namespace created via unshare() and joined via
setns().
Second testcase "pidns_init_via_setns_set_tid" checks that during this
process we can use clone3() + set_tid and set the pid in both the new
and old pid namespaces (owned by different user namespaces). This test
requires root to run to avoid complex setup for wrapper userns.
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
--
pidns_init_via_setns. Make pidns_init_via_setns_set_tid require root.
Link: https://patch.msgid.link/20260318122157.280595-5-ptikhomirov@virtuozzo.com
v6: Move wrapper userns creation for unprivileged case to the top of
Signed-off-by: Christian Brauner <brauner@kernel.org>
The way the test target was defined before, when building with clang we
get a command line like this:
clang -Wall -Werror -g -I../../../../usr/include/ \
regression_enomem.c ../pidfd/pidfd.h -o regression_enomem
This yields an error, because clang thinks we want to produce both a *.o
file, as well as a precompiled header:
clang: error: cannot specify -o when generating multiple output files
gcc, for whatever reason, doesn't exhibit the same behavior which I
suspect is why the problem wasn't noticed before.
This can be fixed simply by using the LOCAL_HDRS infrastructure the
selftests lib.mk provides. It does the right think and marks the target
as depending on the header (so if the header changes, we rebuild), but
it filters the header out of the compiler command line, so we don't get
the error described above.
Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
We recently regressed (cf. [1] and its corresponding fix in [2]) returning
ENOMEM when trying to create a process in a pid namespace whose init
process/child subreaper has already died. This has caused confusion at
least once before that (cf. [3]). Let's add a simple regression test to
catch this in the future.
[1]: 49cb2fc42c ("fork: extend clone3() to support setting a PID")
[2]: b26ebfe12f ("pid: Fix error return value in some cases")
[3]: 35f71bc0a0 ("fork: report pid reservation failure properly")
Cc: Corey Minyard <cminyard@mvista.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Adrian Reber <areber@redhat.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
