linux/include
Christian Brauner 7863dcc72d
pid: allow pid_max to be set per pid namespace
The pid_max sysctl is a global value. For a long time the default value
has been 65535 and during the pidfd dicussions Linus proposed to bump
pid_max by default (cf. [1]). Based on this discussion systemd started
bumping pid_max to 2^22. So all new systems now run with a very high
pid_max limit with some distros having also backported that change.
The decision to bump pid_max is obviously correct. It just doesn't make
a lot of sense nowadays to enforce such a low pid number. There's
sufficient tooling to make selecting specific processes without typing
really large pid numbers available.

In any case, there are workloads that have expections about how large
pid numbers they accept. Either for historical reasons or architectural
reasons. One concreate example is the 32-bit version of Android's bionic
libc which requires pid numbers less than 65536. There are workloads
where it is run in a 32-bit container on a 64-bit kernel. If the host
has a pid_max value greater than 65535 the libc will abort thread
creation because of size assumptions of pthread_mutex_t.

That's a fairly specific use-case however, in general specific workloads
that are moved into containers running on a host with a new kernel and a
new systemd can run into issues with large pid_max values. Obviously
making assumptions about the size of the allocated pid is suboptimal but
we have userspace that does it.

Of course, giving containers the ability to restrict the number of
processes in their respective pid namespace indepent of the global limit
through pid_max is something desirable in itself and comes in handy in
general.

Independent of motivating use-cases the existence of pid namespaces
makes this also a good semantical extension and there have been prior
proposals pushing in a similar direction.
The trick here is to minimize the risk of regressions which I think is
doable. The fact that pid namespaces are hierarchical will help us here.

What we mostly care about is that when the host sets a low pid_max
limit, say (crazy number) 100 that no descendant pid namespace can
allocate a higher pid number in its namespace. Since pid allocation is
hierarchial this can be ensured by checking each pid allocation against
the pid namespace's pid_max limit. This means if the allocation in the
descendant pid namespace succeeds, the ancestor pid namespace can reject
it. If the ancestor pid namespace has a higher limit than the descendant
pid namespace the descendant pid namespace will reject the pid
allocation. The ancestor pid namespace will obviously not care about
this.
All in all this means pid_max continues to enforce a system wide limit
on the number of processes but allows pid namespaces sufficient leeway
in handling workloads with assumptions about pid values and allows
containers to restrict the number of processes in a pid namespace
through the pid_max interface.

[1]: https://lore.kernel.org/linux-api/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com
- rebased from 5.14-rc1
- a few fixes (missing ns_free_inum on error path, missing initialization, etc)
- permission check changes in pid_table_root_permissions
- unsigned int pid_max -> int pid_max (keep pid_max type as it was)
- add READ_ONCE in alloc_pid() as suggested by Christian
- rebased from 6.7 and take into account:
 * sysctl: treewide: drop unused argument ctl_table_root::set_ownership(table)
 * sysctl: treewide: constify ctl_table_header::ctl_table_arg
 * pidfd: add pidfs
 * tracing: Move saved_cmdline code into trace_sched_switch.c

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Link: https://lore.kernel.org/r/20241122132459.135120-2-aleksandr.mikhalitsyn@canonical.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
History 2024-12-02 11:25:25 +01:00
..
acpi common: switch back from remove_new() to remove() callback 2024-11-25 17:31:39 -08:00
asm-generic - Fix a case where posix timers with a thread-group-wide target would miss 2024-12-01 12:41:21 -08:00
clocksource pwm: xilinx: Fix u32 overflow issue in 32-bit width PWM mode. 2024-06-03 13:07:56 +02:00
crypto This update includes the following changes: 2024-11-19 10:28:41 -08:00
cxl cxl: Move mailbox related bits to the same context 2024-09-12 08:38:01 -07:00
drm drm for 6.13-rc1 2024-11-21 14:56:17 -08:00
dt-bindings Char/Misc/IIO/Whatever driver subsystem updates for 6.13-rc1 2024-11-29 11:58:27 -08:00
keys KEYS: Remove unused declarations 2024-09-20 18:28:26 +03:00
kunit The core framework gained a clk provider helper, a clk consumer helper, and 2024-11-22 17:02:25 -08:00
kvm KVM: arm64: vgic: Kill VGIC_MAX_PRIVATE definition 2024-11-20 17:21:08 -08:00
linux pid: allow pid_max to be set per pid namespace 2024-12-02 11:25:25 +01:00
math-emu powerpc/math-emu: Remove -w build flag and fix warnings 2022-09-05 17:28:25 +10:00
media media: replace obsolete hans.verkuil@cisco.com alias 2024-11-08 13:38:09 +01:00
memory memory: renesas-rpc-if: Remove Runtime PM wrappers 2023-01-23 11:48:00 +01:00
misc cxl: fix typo in comment 2022-11-24 23:12:19 +11:00
net Kbuild updates for v6.13 2024-11-30 13:41:50 -08:00
pcmcia ARM: pxa/sa1100: move I/O space to PCI_IOBASE 2022-05-07 22:56:17 +02:00
ras mm/memory-failure: remove obsolete MF_MSG_DIFFERENT_COMPOUND 2024-07-12 15:52:22 -07:00
rdma RDMA/core: Move ib_uverbs_file struct to uverbs_types.h 2024-11-04 06:57:21 -05:00
rv rv: Set variable 'da_mon_##name' to static 2023-09-01 21:00:00 -04:00
scsi Random number generator updates for Linux 6.13-rc1. 2024-11-19 10:43:44 -08:00
soc The core framework gained a clk provider helper, a clk consumer helper, and 2024-11-22 17:02:25 -08:00
sound ALSA: hda/tas2781: Add speaker id check for ASUS projects 2024-11-26 08:54:08 +01:00
target move asm/unaligned.h to linux/unaligned.h 2024-10-02 17:23:23 -04:00
trace NFS client updates for Linux 6.13 2024-11-30 10:17:53 -08:00
uapi io_uring-6.13-20242901 2024-11-30 15:43:02 -08:00
ufs scsi: ufs: ufs-mediatek: Configure individual LU queue flags 2024-11-06 20:42:17 -05:00
vdso vdso: Rename struct arch_vdso_data to arch_vdso_time_data 2024-11-02 12:37:36 +01:00
video - Improved handling of LCD power states and interactions with the fbdev subsystem. 2024-11-22 16:29:57 -08:00
xen xen: Remove dependency between pciback and privcmd 2024-10-18 11:59:04 +02:00