linux/tools/testing/selftests/pid_namespace/Makefile

# SPDX-License-Identifier: GPL-2.0
CFLAGS += -g $(KHDR_INCLUDES)

TEST_GEN_PROGS = regression_enomem pid_max

LOCAL_HDRS += $(selfdir)/pidfd/pidfd.h

include ../lib.mk
selftests: add pid namespace ENOMEM regression test 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]: 49cb2fc42ce4 ("fork: extend clone3() to support setting a PID") [2]: b26ebfe12f34 ("pid: Fix error return value in some cases") [3]: 35f71bc0a09a ("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> 2020-03-08 17:26:32 +01:00			`# SPDX-License-Identifier: GPL-2.0`
selftests: pid_namespace: Fix incorrect kernel headers search path Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents building against kernel headers from the build environment in scenarios where kernel headers are installed into a specific output directory (O=...). Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: linux-kselftest@vger.kernel.org Cc: Ingo Molnar <mingo@redhat.com> Cc: <stable@vger.kernel.org> # 5.18+ Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 2023-01-27 08:57:40 -05:00			`CFLAGS += -g $(KHDR_INCLUDES)`
selftests: add pid namespace ENOMEM regression test 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]: 49cb2fc42ce4 ("fork: extend clone3() to support setting a PID") [2]: b26ebfe12f34 ("pid: Fix error return value in some cases") [3]: 35f71bc0a09a ("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> 2020-03-08 17:26:32 +01:00
tests/pid_namespace: add pid_max tests Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Link: https://lore.kernel.org/r/20241122132459.135120-3-aleksandr.mikhalitsyn@canonical.com Signed-off-by: Christian Brauner <brauner@kernel.org> 2024-11-22 14:24:59 +01:00			`TEST_GEN_PROGS = regression_enomem pid_max`
selftests: add pid namespace ENOMEM regression test 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]: 49cb2fc42ce4 ("fork: extend clone3() to support setting a PID") [2]: b26ebfe12f34 ("pid: Fix error return value in some cases") [3]: 35f71bc0a09a ("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> 2020-03-08 17:26:32 +01:00
selftests: fix header dependency for pid_namespace selftests 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> 2022-03-24 15:39:28 -07:00			`LOCAL_HDRS += $(selfdir)/pidfd/pidfd.h`
selftests: add pid namespace ENOMEM regression test 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]: 49cb2fc42ce4 ("fork: extend clone3() to support setting a PID") [2]: b26ebfe12f34 ("pid: Fix error return value in some cases") [3]: 35f71bc0a09a ("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> 2020-03-08 17:26:32 +01:00
selftests: fix header dependency for pid_namespace selftests 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> 2022-03-24 15:39:28 -07:00			`include ../lib.mk`