Revert "pid: allow pid_max to be set per pid namespace"

Revert "pid: allow pid_max to be set per pid namespace"

Patch series "Alternative "pid_max" for 32-bit userspace".

pid_max is sort of a legacy limit (its value and partially the concept
too, given the existence of pids cgroup controller).  It is tempting to
make the pid_max value part of a pid namespace to provide compat
environment for 32-bit applications [1].  On the other hand, it provides
yet another mechanism for limitation of task count.  Even without
namespacing of pid_max value, the configuration of conscious limit is
confusing for users [2].

This series builds upon the idea of restricting the number (amount) of
tasks by pids controller and ensuring that number (pid) never exceeds the
amount of tasks.  This would not currently work out of the box because
next-fit pid allocation would continue to assign numbers (pids) higher
than the actual amount (there would be gaps in the lower range of the
interval).  The patch 2/2 implements this idea by extending semantics of
ns_last_pid knob to allow first-fit numbering.  (The implementation has
clumsy ifdefery, which can might be dropped since it's too x86-centric.)

The patch 1/2 is a mere revert to simplify pid_max to one global limit
only.

[1] https://lore.kernel.org/r/20241122132459.135120-1-aleksandr.mikhalitsyn@canonical.com/
[2] https://lore.kernel.org/r/bnxhqrq7tip6jl2hu6jsvxxogdfii7ugmafbhgsogovrchxfyp@kagotkztqurt/

This patch (of 2):

This reverts commit 7863dcc72d0f4b13a641065670426435448b3d80.

It is already difficult for users to troubleshoot which of multiple pid
limits restricts their workload.  I'm afraid making pid_max
per-(hierarchical-)NS will contribute to confusion.  Also, the
implementation copies the limit upon creation from parent, this pattern
showed cumbersome with some attributes in legacy cgroup controllers --
it's subject to race condition between parent's limit modification and
children creation and once copied it must be changed in the descendant.

This is very similar to what pids.max of a cgroup (already) does that can
be used as an alternative.

Link: https://lkml.kernel.org/r/20250221170249.890014-1-mkoutny@suse.com
Link: https://lore.kernel.org/r/bnxhqrq7tip6jl2hu6jsvxxogdfii7ugmafbhgsogovrchxfyp@kagotkztqurt/
Link: https://lkml.kernel.org/r/20250221170249.890014-2-mkoutny@suse.com
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Cc: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <kees@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>