From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752329AbbCNEhw (ORCPT ); Sat, 14 Mar 2015 00:37:52 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:33525 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751939AbbCNEhj (ORCPT ); Sat, 14 Mar 2015 00:37:39 -0400 From: Aleksa Sarai To: tj@kernel.org, lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org Cc: richard@nod.at, fweisbec@gmail.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Aleksa Sarai Subject: [PATCH v6 3/3] cgroups: add a pids subsystem Date: Sat, 14 Mar 2015 15:37:15 +1100 Message-Id: <1426307835-5893-4-git-send-email-cyphar@cyphar.com> X-Mailer: git-send-email 2.3.2 In-Reply-To: <1426307835-5893-1-git-send-email-cyphar@cyphar.com> References: <1426307835-5893-1-git-send-email-cyphar@cyphar.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 will 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. 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 --- include/linux/cgroup_subsys.h | 4 + init/Kconfig | 11 ++ kernel/Makefile | 1 + kernel/cgroup_pids.c | 301 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 317 insertions(+) create mode 100644 kernel/cgroup_pids.c diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h index e4a96fb..a198822 100644 --- a/include/linux/cgroup_subsys.h +++ b/include/linux/cgroup_subsys.h @@ -47,6 +47,10 @@ SUBSYS(net_prio) SUBSYS(hugetlb) #endif +#if IS_ENABLED(CONFIG_CGROUP_PIDS) +SUBSYS(pids) +#endif + /* * The following subsystems are not supported on the default hierarchy. */ diff --git a/init/Kconfig b/init/Kconfig index f5dbc6d..88364c9 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1054,6 +1054,17 @@ config CGROUP_HUGETLB control group is tracked in the third page lru pointer. This means that we cannot use the controller with huge page less than 3 pages. +config CGROUP_PIDS + bool "Process number limiting on cgroups" + help + This options enables the setting 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. + config CGROUP_PERF bool "Enable perf_event per-cpu per-container group (cgroup) monitoring" depends on PERF_EVENTS && CGROUPS diff --git a/kernel/Makefile b/kernel/Makefile index 1408b33..e823592 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o obj-$(CONFIG_COMPAT) += compat.o obj-$(CONFIG_CGROUPS) += cgroup.o obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o +obj-$(CONFIG_CGROUP_PIDS) += cgroup_pids.o obj-$(CONFIG_CPUSETS) += cpuset.o obj-$(CONFIG_UTS_NS) += utsname.o obj-$(CONFIG_USER_NS) += user_namespace.o diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c new file mode 100644 index 0000000..436e4c7 --- /dev/null +++ b/kernel/cgroup_pids.c @@ -0,0 +1,301 @@ +/* + * Process number limiting controller for cgroups. + * + * Used to allow a cgroup hierarchy to stop any new processes + * from fork()ing after a certain limit is reached. + * + * Since it is trivial to hit the task limit without hitting + * any kmemcg limits in place, PIDs are a fundamental resource. + * As such, PID exhaustion must be preventable in the scope of + * a cgroup hierarchy by allowing resource limiting of the + * number of tasks in a cgroup. + * + * In order to use the `pids` controller, set the maximum number + * of tasks in pids.max (this is not available in the root cgroup + * for obvious reasons). The number of processes currently + * in the cgroup is given by pids.current. Organisational operations + * are not blocked by cgroup policies, so it is possible to have + * pids.current > pids.max. However, fork()s will still not work. + * + * To set a cgroup to have no limit, set pids.max to "max". fork() + * will return -EBUSY if forking would cause a cgroup policy to be + * violated. + * + * pids.current tracks all child cgroup hierarchies, so + * parent/pids.current is a superset of parent/child/pids.current. + * + * Copyright (C) 2015 Aleksa Sarai + * + */ + +#include +#include +#include +#include +#include + +#define PIDS_MAX (PID_MAX_LIMIT + 1ULL) +#define PIDS_MAX_STR "max" + +struct pids_cgroup { + struct cgroup_subsys_state css; + + /* + * Use 64-bit types so that we can safely represent "max" as + * (PID_MAX_LIMIT + 1). + */ + atomic64_t counter; + int64_t limit; +}; + +static struct pids_cgroup *css_pids(struct cgroup_subsys_state *css) +{ + return container_of(css, struct pids_cgroup, css); +} + +static struct pids_cgroup *parent_pids(struct pids_cgroup *pids) +{ + return css_pids(pids->css.parent); +} + +static struct cgroup_subsys_state * +pids_css_alloc(struct cgroup_subsys_state *parent) +{ + struct pids_cgroup *pids; + + pids = kzalloc(sizeof(struct pids_cgroup), GFP_KERNEL); + if (!pids) + return ERR_PTR(-ENOMEM); + + pids->limit = PIDS_MAX; + atomic64_set(&pids->counter, 0); + return &pids->css; +} + +static void pids_css_free(struct cgroup_subsys_state *css) +{ + kfree(css_pids(css)); +} + +/** + * pids_cancel - uncharge the local pid count + * @pids: the pid cgroup state + * @num: the number of pids to cancel + * + * This function will WARN if the pid count goes under 0, + * because such a case is a bug in the pids controller proper. + */ +static void pids_cancel(struct pids_cgroup *pids, int num) +{ + /* + * A negative count (or overflow for that matter) is invalid, + * and indicates a bug in the pids controller proper. + */ + WARN_ON_ONCE(atomic64_add_negative(-num, &pids->counter)); +} + +/** + * pids_uncharge - hierarchically uncharge the pid count + * @pids: the pid cgroup state + * @num: the number of pids to uncharge + */ +static void pids_uncharge(struct pids_cgroup *pids, int num) +{ + struct pids_cgroup *p; + + for (p = pids; p; p = parent_pids(p)) + pids_cancel(p, num); +} + +/** + * pids_charge - hierarchically charge the pid count + * @pids: the pid cgroup state + * @num: the number of pids to charge + * + * This function does *not* follow the pid limit set. It cannot + * fail and the new pid count may exceed the limit, because + * organisational operations cannot fail in the unified hierarchy. + */ +static void pids_charge(struct pids_cgroup *pids, int num) +{ + struct pids_cgroup *p; + + for (p = pids; p; p = parent_pids(p)) + atomic64_add(num, &p->counter); +} + +/** + * pids_try_charge - hierarchically try to charge the pid count + * @pids: the pid cgroup state + * @num: the number of pids to charge + * + * This function follows the set limit. It will fail if the charge + * would cause the new value to exceed the hierarchical limit. + * Returns 0 if the charge succeded, otherwise -EAGAIN. + */ +static int pids_try_charge(struct pids_cgroup *pids, int num) +{ + struct pids_cgroup *p, *q; + + for (p = pids; p; p = parent_pids(p)) { + int64_t new = atomic64_add_return(num, &p->counter); + + if (new > p->limit) + goto revert; + } + + return 0; + +revert: + for (q = pids; q != p; q = parent_pids(q)) + pids_cancel(q, num); + pids_cancel(p, num); + + return -EAGAIN; +} + +static int pids_can_attach(struct cgroup_subsys_state *css, + struct cgroup_taskset *tset) +{ + struct pids_cgroup *pids = css_pids(css); + struct task_struct *task; + int64_t num = 0; + + cgroup_taskset_for_each(task, tset) + num++; + + /* + * Attaching to a cgroup is allowed to overcome the + * the PID limit, so that organisation operations aren't + * blocked by the `pids` cgroup controller. + */ + pids_charge(pids, num); + return 0; +} + +static void pids_cancel_attach(struct cgroup_subsys_state *css, + struct cgroup_taskset *tset) +{ + struct pids_cgroup *pids = css_pids(css); + struct task_struct *task; + int64_t num = 0; + + cgroup_taskset_for_each(task, tset) + num++; + + pids_uncharge(pids, num); +} + +static int pids_can_fork(struct cgroup_subsys_state *css, + struct task_struct *task) +{ + struct pids_cgroup *pids = css_pids(css); + + return pids_try_charge(pids, 1); +} + +static void pids_cancel_fork(struct cgroup_subsys_state *css, + struct task_struct *task) +{ + struct pids_cgroup *pids = css_pids(css); + + pids_uncharge(pids, 1); +} + +static void pids_reapply_fork(struct cgroup_subsys_state *css, + struct cgroup_subsys_state *old_css, + struct task_struct *task) +{ + struct pids_cgroup *pids = css_pids(css), + *old_pids = css_pids(old_css); + + pids_uncharge(old_pids, 1); + pids_charge(pids, 1); +} + +static void pids_exit(struct cgroup_subsys_state *css, + struct cgroup_subsys_state *old_css, + struct task_struct *task) +{ + struct pids_cgroup *pids = css_pids(old_css); + + pids_uncharge(pids, 1); +} + +static ssize_t pids_max_write(struct kernfs_open_file *of, char *buf, + size_t nbytes, loff_t off) +{ + struct cgroup_subsys_state *css = of_css(of); + struct pids_cgroup *pids = css_pids(css); + int64_t limit; + int err; + + buf = strstrip(buf); + if (!strcmp(buf, PIDS_MAX_STR)) { + pids->limit = PIDS_MAX; + return nbytes; + } + + err = kstrtoll(buf, 0, &limit); + if (err) + return err; + + if (limit < 0 || limit > INT_MAX) + return -EINVAL; + + /* + * Limit updates don't need to be mutex'd, since it isn't + * critical that any racing fork()s follow the new limit. + */ + pids->limit = limit; + return nbytes; +} + +static int pids_max_show(struct seq_file *sf, void *v) +{ + struct cgroup_subsys_state *css = seq_css(sf); + struct pids_cgroup *pids = css_pids(css); + int64_t limit = pids->limit; + + if (limit == PIDS_MAX) + seq_printf(sf, "%s\n", PIDS_MAX_STR); + else + seq_printf(sf, "%lld\n", limit); + + return 0; +} + +static s64 pids_current_read(struct cgroup_subsys_state *css, + struct cftype *cft) +{ + struct pids_cgroup *pids = css_pids(css); + + return atomic64_read(&pids->counter); +} + +static struct cftype files[] = { + { + .name = "max", + .write = pids_max_write, + .seq_show = pids_max_show, + .flags = CFTYPE_NOT_ON_ROOT, + }, + { + .name = "current", + .read_s64 = pids_current_read, + }, + { } /* terminate */ +}; + +struct cgroup_subsys pids_cgrp_subsys = { + .css_alloc = pids_css_alloc, + .css_free = pids_css_free, + .can_attach = pids_can_attach, + .cancel_attach = pids_cancel_attach, + .can_fork = pids_can_fork, + .cancel_fork = pids_cancel_fork, + .reapply_fork = pids_reapply_fork, + .exit = pids_exit, + .legacy_cftypes = files, + .early_init = 0, +}; -- 2.3.2