summaryrefslogtreecommitdiff
path: root/init
diff options
context:
space:
mode:
authorAleksa Sarai <cyphar@cyphar.com>2015-06-09 21:32:10 +1000
committerTejun Heo <tj@kernel.org>2015-07-14 17:29:23 -0400
commit49b786ea146f69c371df18e81ce0a2d5839f865c (patch)
tree8e7abdd61fb2a8e5d3b7ffbf263fc36d8f9969f5 /init
parent7e47682ea555e7c1edef1d8fd96e2aa4c12abe59 (diff)
cgroup: implement the PIDs subsystem
Adds a new single-purpose PIDs subsystem to limit the number of tasks that can be forked inside a cgroup. Essentially this is an implementation of RLIMIT_NPROC that applies to a cgroup rather than a process tree. However, it should be noted that organisational operations (adding and removing tasks from a PIDs hierarchy) will *not* be prevented. Rather, the number of tasks in the hierarchy cannot exceed the limit through forking. This is due to the fact that, in the unified hierarchy, attach cannot fail (and it is not possible for a task to overcome its PIDs cgroup policy limit by attaching to a child cgroup -- even if migrating mid-fork it must be able to fork in the parent first). PIDs are fundamentally a global resource, and it is possible to reach PID exhaustion inside a cgroup without hitting any reasonable kmemcg policy. Once you've hit PID exhaustion, you're only in a marginally better state than OOM. This subsystem allows PID exhaustion inside a cgroup to be prevented. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'init')
-rw-r--r--init/Kconfig16
1 files changed, 16 insertions, 0 deletions
diff --git a/init/Kconfig b/init/Kconfig
index af09b4fb43d2..2184b34cbf73 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -955,6 +955,22 @@ config CGROUP_FREEZER
Provides a way to freeze and unfreeze all tasks in a
cgroup.
+config CGROUP_PIDS
+ bool "PIDs cgroup subsystem"
+ help
+ Provides enforcement of process number limits in the scope of a
+ cgroup. Any attempt to fork more processes than is allowed in the
+ cgroup will fail. PIDs are fundamentally a global resource because it
+ is fairly trivial to reach PID exhaustion before you reach even a
+ conservative kmemcg limit. As a result, it is possible to grind a
+ system to halt without being limited by other cgroup policies. The
+ PIDs cgroup subsystem is designed to stop this from happening.
+
+ It should be noted that organisational operations (such as attaching
+ to a cgroup hierarchy will *not* be blocked by the PIDs subsystem),
+ since the PIDs limit only affects a process's ability to fork, not to
+ attach to a cgroup.
+
config CGROUP_DEVICE
bool "Device controller for cgroups"
help