Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
#ifndef _LINUX_CGROUP_H
|
|
|
|
#define _LINUX_CGROUP_H
|
|
|
|
/*
|
|
|
|
* cgroup interface
|
|
|
|
*
|
|
|
|
* Copyright (C) 2003 BULL SA
|
|
|
|
* Copyright (C) 2004-2006 Silicon Graphics, Inc.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/cpumask.h>
|
|
|
|
#include <linux/nodemask.h>
|
2012-11-10 01:12:29 +08:00
|
|
|
#include <linux/rculist.h>
|
Add cgroupstats
This patch is inspired by the discussion at
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
as suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263. The
patch is on top of 2.6.21-mm1 with Paul's cgroups v9 patches (forward
ported)
This patch implements per cgroup statistics infrastructure and re-uses
code from the taskstats interface. A new set of cgroup operations are
registered with commands and attributes. It should be very easy to
*extend* per cgroup statistics, by adding members to the cgroupstats
structure.
The current model for cgroupstats is a pull, a push model (to post
statistics on interesting events), should be very easy to add. Currently
user space requests for statistics by passing the cgroup file
descriptor. Statistics about the state of all the tasks in the cgroup
is returned to user space.
TODO's/NOTE:
This patch provides an infrastructure for implementing cgroup statistics.
Based on the needs of each controller, we can incrementally add more statistics,
event based support for notification of statistics, accumulation of taskstats
into cgroup statistics in the future.
Sample output
# ./cgroupstats -C /cgroup/a
sleeping 2, blocked 0, running 1, stopped 0, uninterruptible 0
# ./cgroupstats -C /cgroup/
sleeping 154, blocked 0, running 0, stopped 0, uninterruptible 0
If the approach looks good, I'll enhance and post the user space utility for
the same
Feedback, comments, test results are always welcome!
[akpm@linux-foundation.org: build fix]
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Jay Lan <jlan@engr.sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:44 +08:00
|
|
|
#include <linux/cgroupstats.h>
|
2013-04-15 11:15:25 +08:00
|
|
|
#include <linux/fs.h>
|
2013-12-06 01:28:04 +08:00
|
|
|
#include <linux/seq_file.h>
|
cgroup: convert to kernfs
cgroup filesystem code was derived from the original sysfs
implementation which was heavily intertwined with vfs objects and
locking with the goal of re-using the existing vfs infrastructure.
That experiment turned out rather disastrous and sysfs switched, a
long time ago, to distributed filesystem model where a separate
representation is maintained which is queried by vfs. Unfortunately,
cgroup stuck with the failed experiment all these years and
accumulated even more problems over time.
Locking and object lifetime management being entangled with vfs is
probably the most egregious. vfs is never designed to be misused like
this and cgroup ends up jumping through various convoluted dancing to
make things work. Even then, operations across multiple cgroups can't
be done safely as it'll deadlock with rename locking.
Recently, kernfs is separated out from sysfs so that it can be used by
users other than sysfs. This patch converts cgroup to use kernfs,
which will bring the following benefits.
* Separation from vfs internals. Locking and object lifetime
management is contained in cgroup proper making things a lot
simpler. This removes significant amount of locking convolutions,
hairy object lifetime rules and the restriction on multi-cgroup
operations.
* Can drop a lot of code to implement filesystem interface as most are
provided by kernfs.
* Proper "severing" semantics, which allows controllers to not worry
about lingering file accesses after offline.
While the preceding patches did as much as possible to make the
transition less painful, large part of the conversion has to be one
discrete step making this patch rather large. The rest of the commit
message lists notable changes in different areas.
Overall
-------
* vfs constructs replaced with kernfs ones. cgroup->dentry w/ ->kn,
cgroupfs_root->sb w/ ->kf_root.
* All dentry accessors are removed. Helpers to map from kernfs
constructs are added.
* All vfs plumbing around dentry, inode and bdi removed.
* cgroup_mount() now directly looks for matching root and then
proceeds to create a new one if not found.
Synchronization and object lifetime
-----------------------------------
* vfs inode locking removed. Among other things, this removes the
need for the convolution in cgroup_cfts_commit(). Future patches
will further simplify it.
* vfs refcnting replaced with cgroup internal ones. cgroup->refcnt,
cgroupfs_root->refcnt added. cgroup_put_root() now directly puts
root->refcnt and when it reaches zero proceeds to destroy it thus
merging cgroup_put_root() and the former cgroup_kill_sb().
Simliarly, cgroup_put() now directly schedules cgroup_free_rcu()
when refcnt reaches zero.
* Unlike before, kernfs objects don't hold onto cgroup objects. When
cgroup destroys a kernfs node, all existing operations are drained
and the association is broken immediately. The same for
cgroupfs_roots and mounts.
* All operations which come through kernfs guarantee that the
associated cgroup is and stays valid for the duration of operation;
however, there are two paths which need to find out the associated
cgroup from dentry without going through kernfs -
css_tryget_from_dir() and cgroupstats_build(). For these two,
kernfs_node->priv is RCU managed so that they can dereference it
under RCU read lock.
File and directory handling
---------------------------
* File and directory operations converted to kernfs_ops and
kernfs_syscall_ops.
* xattrs is implicitly supported by kernfs. No need to worry about it
from cgroup. This means that "xattr" mount option is no longer
necessary. A future patch will add a deprecated warning message
when sane_behavior.
* When cftype->max_write_len > PAGE_SIZE, it's necessary to make a
private copy of one of the kernfs_ops to set its atomic_write_len.
cftype->kf_ops is added and cgroup_init/exit_cftypes() are updated
to handle it.
* cftype->lockdep_key added so that kernfs lockdep annotation can be
per cftype.
* Inidividual file entries and open states are now managed by kernfs.
No need to worry about them from cgroup. cfent, cgroup_open_file
and their friends are removed.
* kernfs_nodes are created deactivated and kernfs_activate()
invocations added to places where creation of new nodes are
committed.
* cgroup_rmdir() uses kernfs_[un]break_active_protection() for
self-removal.
v2: - Li pointed out in an earlier patch that specifying "name="
during mount without subsystem specification should succeed if
there's an existing hierarchy with a matching name although it
should fail with -EINVAL if a new hierarchy should be created.
Prior to the conversion, this used by handled by deferring
failure from NULL return from cgroup_root_from_opts(), which was
necessary because root was being created before checking for
existing ones. Note that cgroup_root_from_opts() returned an
ERR_PTR() value for error conditions which require immediate
mount failure.
As we now have separate search and creation steps, deferring
failure from cgroup_root_from_opts() is no longer necessary.
cgroup_root_from_opts() is updated to always return ERR_PTR()
value on failure.
- The logic to match existing roots is updated so that a mount
attempt with a matching name but different subsys_mask are
rejected. This was handled by a separate matching loop under
the comment "Check for name clashes with existing mounts" but
got lost during conversion. Merge the check into the main
search loop.
- Add __rcu __force casting in RCU_INIT_POINTER() in
cgroup_destroy_locked() to avoid the sparse address space
warning reported by kbuild test bot. Maybe we want an explicit
interface to use kn->priv as RCU protected pointer?
v3: Make CONFIG_CGROUPS select CONFIG_KERNFS.
v4: Rebased on top of 0ab02ca8f887 ("cgroup: protect modifications to
cgroup_idr with cgroup_mutex").
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: kbuild test robot fengguang.wu@intel.com>
2014-02-12 00:52:49 +08:00
|
|
|
#include <linux/kernfs.h>
|
2015-09-18 23:56:28 +08:00
|
|
|
#include <linux/jump_label.h>
|
2016-01-29 16:54:06 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/ns_common.h>
|
|
|
|
#include <linux/nsproxy.h>
|
|
|
|
#include <linux/user_namespace.h>
|
2017-02-20 18:19:00 +08:00
|
|
|
#include <linux/refcount.h>
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-05-14 03:38:40 +08:00
|
|
|
#include <linux/cgroup-defs.h>
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_CGROUPS
|
|
|
|
|
2015-08-05 03:20:55 +08:00
|
|
|
/*
|
|
|
|
* All weight knobs on the default hierarhcy should use the following min,
|
|
|
|
* default and max values. The default value is the logarithmic center of
|
|
|
|
* MIN and MAX and allows 100x to be expressed in both directions.
|
|
|
|
*/
|
|
|
|
#define CGROUP_WEIGHT_MIN 1
|
|
|
|
#define CGROUP_WEIGHT_DFL 100
|
|
|
|
#define CGROUP_WEIGHT_MAX 10000
|
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
/* a css_task_iter should be treated as an opaque object */
|
|
|
|
struct css_task_iter {
|
|
|
|
struct cgroup_subsys *ss;
|
|
|
|
|
|
|
|
struct list_head *cset_pos;
|
|
|
|
struct list_head *cset_head;
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
struct list_head *task_pos;
|
|
|
|
struct list_head *tasks_head;
|
|
|
|
struct list_head *mg_tasks_head;
|
2015-10-16 04:41:52 +08:00
|
|
|
|
|
|
|
struct css_set *cur_cset;
|
|
|
|
struct task_struct *cur_task;
|
|
|
|
struct list_head iters_node; /* css_set->task_iters */
|
2015-05-14 04:24:16 +08:00
|
|
|
};
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
extern struct cgroup_root cgrp_dfl_root;
|
|
|
|
extern struct css_set init_css_set;
|
2007-10-19 14:39:35 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
#define SUBSYS(_x) extern struct cgroup_subsys _x ## _cgrp_subsys;
|
2007-10-19 14:39:36 +08:00
|
|
|
#include <linux/cgroup_subsys.h>
|
|
|
|
#undef SUBSYS
|
|
|
|
|
2015-09-18 23:56:28 +08:00
|
|
|
#define SUBSYS(_x) \
|
|
|
|
extern struct static_key_true _x ## _cgrp_subsys_enabled_key; \
|
|
|
|
extern struct static_key_true _x ## _cgrp_subsys_on_dfl_key;
|
|
|
|
#include <linux/cgroup_subsys.h>
|
|
|
|
#undef SUBSYS
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cgroup_subsys_enabled - fast test on whether a subsys is enabled
|
|
|
|
* @ss: subsystem in question
|
|
|
|
*/
|
|
|
|
#define cgroup_subsys_enabled(ss) \
|
|
|
|
static_branch_likely(&ss ## _enabled_key)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cgroup_subsys_on_dfl - fast test on whether a subsys is on default hierarchy
|
|
|
|
* @ss: subsystem in question
|
|
|
|
*/
|
|
|
|
#define cgroup_subsys_on_dfl(ss) \
|
|
|
|
static_branch_likely(&ss ## _on_dfl_key)
|
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
bool css_has_online_children(struct cgroup_subsys_state *css);
|
|
|
|
struct cgroup_subsys_state *css_from_id(int id, struct cgroup_subsys *ss);
|
|
|
|
struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup *cgroup,
|
|
|
|
struct cgroup_subsys *ss);
|
|
|
|
struct cgroup_subsys_state *css_tryget_online_from_dir(struct dentry *dentry,
|
|
|
|
struct cgroup_subsys *ss);
|
|
|
|
|
2015-11-21 04:55:52 +08:00
|
|
|
struct cgroup *cgroup_get_from_path(const char *path);
|
2016-07-01 01:28:42 +08:00
|
|
|
struct cgroup *cgroup_get_from_fd(int fd);
|
2015-11-21 04:55:52 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
|
|
|
|
int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
|
|
|
|
|
|
|
|
int cgroup_add_dfl_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
|
|
|
|
int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
|
|
|
|
int cgroup_rm_cftypes(struct cftype *cfts);
|
2015-11-05 13:12:24 +08:00
|
|
|
void cgroup_file_notify(struct cgroup_file *cfile);
|
2015-05-14 04:24:16 +08:00
|
|
|
|
2016-08-10 23:23:44 +08:00
|
|
|
int task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
|
2015-05-14 04:24:16 +08:00
|
|
|
int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry);
|
|
|
|
int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
|
|
|
|
struct pid *pid, struct task_struct *tsk);
|
|
|
|
|
|
|
|
void cgroup_fork(struct task_struct *p);
|
2015-12-03 23:24:08 +08:00
|
|
|
extern int cgroup_can_fork(struct task_struct *p);
|
|
|
|
extern void cgroup_cancel_fork(struct task_struct *p);
|
|
|
|
extern void cgroup_post_fork(struct task_struct *p);
|
2015-05-14 04:24:16 +08:00
|
|
|
void cgroup_exit(struct task_struct *p);
|
2015-10-16 04:41:53 +08:00
|
|
|
void cgroup_free(struct task_struct *p);
|
2015-05-14 04:24:16 +08:00
|
|
|
|
|
|
|
int cgroup_init_early(void);
|
|
|
|
int cgroup_init(void);
|
|
|
|
|
2014-05-17 01:22:48 +08:00
|
|
|
/*
|
2015-05-14 04:24:16 +08:00
|
|
|
* Iteration helpers and macros.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
|
|
|
|
struct cgroup_subsys_state *parent);
|
|
|
|
struct cgroup_subsys_state *css_next_descendant_pre(struct cgroup_subsys_state *pos,
|
|
|
|
struct cgroup_subsys_state *css);
|
|
|
|
struct cgroup_subsys_state *css_rightmost_descendant(struct cgroup_subsys_state *pos);
|
|
|
|
struct cgroup_subsys_state *css_next_descendant_post(struct cgroup_subsys_state *pos,
|
|
|
|
struct cgroup_subsys_state *css);
|
|
|
|
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
struct task_struct *cgroup_taskset_first(struct cgroup_taskset *tset,
|
|
|
|
struct cgroup_subsys_state **dst_cssp);
|
|
|
|
struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
|
|
|
|
struct cgroup_subsys_state **dst_cssp);
|
2015-05-14 04:24:16 +08:00
|
|
|
|
|
|
|
void css_task_iter_start(struct cgroup_subsys_state *css,
|
|
|
|
struct css_task_iter *it);
|
|
|
|
struct task_struct *css_task_iter_next(struct css_task_iter *it);
|
|
|
|
void css_task_iter_end(struct css_task_iter *it);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* css_for_each_child - iterate through children of a css
|
|
|
|
* @pos: the css * to use as the loop cursor
|
|
|
|
* @parent: css whose children to walk
|
|
|
|
*
|
|
|
|
* Walk @parent's children. Must be called under rcu_read_lock().
|
|
|
|
*
|
|
|
|
* If a subsystem synchronizes ->css_online() and the start of iteration, a
|
|
|
|
* css which finished ->css_online() is guaranteed to be visible in the
|
|
|
|
* future iterations and will stay visible until the last reference is put.
|
|
|
|
* A css which hasn't finished ->css_online() or already finished
|
|
|
|
* ->css_offline() may show up during traversal. It's each subsystem's
|
|
|
|
* responsibility to synchronize against on/offlining.
|
2014-05-17 01:22:48 +08:00
|
|
|
*
|
2015-05-14 04:24:16 +08:00
|
|
|
* It is allowed to temporarily drop RCU read lock during iteration. The
|
|
|
|
* caller is responsible for ensuring that @pos remains accessible until
|
|
|
|
* the start of the next iteration by, for example, bumping the css refcnt.
|
2014-05-17 01:22:48 +08:00
|
|
|
*/
|
2015-05-14 04:24:16 +08:00
|
|
|
#define css_for_each_child(pos, parent) \
|
|
|
|
for ((pos) = css_next_child(NULL, (parent)); (pos); \
|
|
|
|
(pos) = css_next_child((pos), (parent)))
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
/**
|
|
|
|
* css_for_each_descendant_pre - pre-order walk of a css's descendants
|
|
|
|
* @pos: the css * to use as the loop cursor
|
|
|
|
* @root: css whose descendants to walk
|
|
|
|
*
|
|
|
|
* Walk @root's descendants. @root is included in the iteration and the
|
|
|
|
* first node to be visited. Must be called under rcu_read_lock().
|
|
|
|
*
|
|
|
|
* If a subsystem synchronizes ->css_online() and the start of iteration, a
|
|
|
|
* css which finished ->css_online() is guaranteed to be visible in the
|
|
|
|
* future iterations and will stay visible until the last reference is put.
|
|
|
|
* A css which hasn't finished ->css_online() or already finished
|
|
|
|
* ->css_offline() may show up during traversal. It's each subsystem's
|
|
|
|
* responsibility to synchronize against on/offlining.
|
|
|
|
*
|
|
|
|
* For example, the following guarantees that a descendant can't escape
|
|
|
|
* state updates of its ancestors.
|
|
|
|
*
|
|
|
|
* my_online(@css)
|
|
|
|
* {
|
|
|
|
* Lock @css's parent and @css;
|
|
|
|
* Inherit state from the parent;
|
|
|
|
* Unlock both.
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* my_update_state(@css)
|
|
|
|
* {
|
|
|
|
* css_for_each_descendant_pre(@pos, @css) {
|
|
|
|
* Lock @pos;
|
|
|
|
* if (@pos == @css)
|
|
|
|
* Update @css's state;
|
|
|
|
* else
|
|
|
|
* Verify @pos is alive and inherit state from its parent;
|
|
|
|
* Unlock @pos;
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* As long as the inheriting step, including checking the parent state, is
|
|
|
|
* enclosed inside @pos locking, double-locking the parent isn't necessary
|
|
|
|
* while inheriting. The state update to the parent is guaranteed to be
|
|
|
|
* visible by walking order and, as long as inheriting operations to the
|
|
|
|
* same @pos are atomic to each other, multiple updates racing each other
|
|
|
|
* still result in the correct state. It's guaranateed that at least one
|
|
|
|
* inheritance happens for any css after the latest update to its parent.
|
|
|
|
*
|
|
|
|
* If checking parent's state requires locking the parent, each inheriting
|
|
|
|
* iteration should lock and unlock both @pos->parent and @pos.
|
|
|
|
*
|
|
|
|
* Alternatively, a subsystem may choose to use a single global lock to
|
|
|
|
* synchronize ->css_online() and ->css_offline() against tree-walking
|
|
|
|
* operations.
|
|
|
|
*
|
|
|
|
* It is allowed to temporarily drop RCU read lock during iteration. The
|
|
|
|
* caller is responsible for ensuring that @pos remains accessible until
|
|
|
|
* the start of the next iteration by, for example, bumping the css refcnt.
|
|
|
|
*/
|
|
|
|
#define css_for_each_descendant_pre(pos, css) \
|
|
|
|
for ((pos) = css_next_descendant_pre(NULL, (css)); (pos); \
|
|
|
|
(pos) = css_next_descendant_pre((pos), (css)))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* css_for_each_descendant_post - post-order walk of a css's descendants
|
|
|
|
* @pos: the css * to use as the loop cursor
|
|
|
|
* @css: css whose descendants to walk
|
|
|
|
*
|
|
|
|
* Similar to css_for_each_descendant_pre() but performs post-order
|
|
|
|
* traversal instead. @root is included in the iteration and the last
|
|
|
|
* node to be visited.
|
|
|
|
*
|
|
|
|
* If a subsystem synchronizes ->css_online() and the start of iteration, a
|
|
|
|
* css which finished ->css_online() is guaranteed to be visible in the
|
|
|
|
* future iterations and will stay visible until the last reference is put.
|
|
|
|
* A css which hasn't finished ->css_online() or already finished
|
|
|
|
* ->css_offline() may show up during traversal. It's each subsystem's
|
|
|
|
* responsibility to synchronize against on/offlining.
|
|
|
|
*
|
|
|
|
* Note that the walk visibility guarantee example described in pre-order
|
|
|
|
* walk doesn't apply the same to post-order walks.
|
|
|
|
*/
|
|
|
|
#define css_for_each_descendant_post(pos, css) \
|
|
|
|
for ((pos) = css_next_descendant_post(NULL, (css)); (pos); \
|
|
|
|
(pos) = css_next_descendant_post((pos), (css)))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cgroup_taskset_for_each - iterate cgroup_taskset
|
|
|
|
* @task: the loop cursor
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
* @dst_css: the destination css
|
2015-05-14 04:24:16 +08:00
|
|
|
* @tset: taskset to iterate
|
2015-09-12 03:00:19 +08:00
|
|
|
*
|
|
|
|
* @tset may contain multiple tasks and they may belong to multiple
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
* processes.
|
|
|
|
*
|
|
|
|
* On the v2 hierarchy, there may be tasks from multiple processes and they
|
|
|
|
* may not share the source or destination csses.
|
|
|
|
*
|
|
|
|
* On traditional hierarchies, when there are multiple tasks in @tset, if a
|
|
|
|
* task of a process is in @tset, all tasks of the process are in @tset.
|
|
|
|
* Also, all are guaranteed to share the same source and destination csses.
|
2015-09-12 03:00:19 +08:00
|
|
|
*
|
|
|
|
* Iteration is not in any specific order.
|
2015-05-14 04:24:16 +08:00
|
|
|
*/
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
#define cgroup_taskset_for_each(task, dst_css, tset) \
|
|
|
|
for ((task) = cgroup_taskset_first((tset), &(dst_css)); \
|
|
|
|
(task); \
|
|
|
|
(task) = cgroup_taskset_next((tset), &(dst_css)))
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-09-12 03:00:19 +08:00
|
|
|
/**
|
|
|
|
* cgroup_taskset_for_each_leader - iterate group leaders in a cgroup_taskset
|
|
|
|
* @leader: the loop cursor
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
* @dst_css: the destination css
|
2016-12-24 23:28:35 +08:00
|
|
|
* @tset: taskset to iterate
|
2015-09-12 03:00:19 +08:00
|
|
|
*
|
|
|
|
* Iterate threadgroup leaders of @tset. For single-task migrations, @tset
|
|
|
|
* may not contain any.
|
|
|
|
*/
|
cgroup: fix handling of multi-destination migration from subtree_control enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
2015-12-03 23:18:21 +08:00
|
|
|
#define cgroup_taskset_for_each_leader(leader, dst_css, tset) \
|
|
|
|
for ((leader) = cgroup_taskset_first((tset), &(dst_css)); \
|
|
|
|
(leader); \
|
|
|
|
(leader) = cgroup_taskset_next((tset), &(dst_css))) \
|
2015-09-12 03:00:19 +08:00
|
|
|
if ((leader) != (leader)->group_leader) \
|
|
|
|
; \
|
|
|
|
else
|
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
/*
|
|
|
|
* Inline functions.
|
|
|
|
*/
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2013-06-13 12:04:52 +08:00
|
|
|
/**
|
|
|
|
* css_get - obtain a reference on the specified css
|
|
|
|
* @css: target css
|
|
|
|
*
|
|
|
|
* The caller must already have a reference.
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
*/
|
|
|
|
static inline void css_get(struct cgroup_subsys_state *css)
|
|
|
|
{
|
2014-05-17 01:22:47 +08:00
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
percpu_ref_get(&css->refcnt);
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
}
|
2009-01-08 10:08:38 +08:00
|
|
|
|
2014-12-11 07:42:42 +08:00
|
|
|
/**
|
|
|
|
* css_get_many - obtain references on the specified css
|
|
|
|
* @css: target css
|
|
|
|
* @n: number of references to get
|
|
|
|
*
|
|
|
|
* The caller must already have a reference.
|
|
|
|
*/
|
|
|
|
static inline void css_get_many(struct cgroup_subsys_state *css, unsigned int n)
|
|
|
|
{
|
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
percpu_ref_get_many(&css->refcnt, n);
|
|
|
|
}
|
|
|
|
|
2014-05-17 01:22:52 +08:00
|
|
|
/**
|
|
|
|
* css_tryget - try to obtain a reference on the specified css
|
|
|
|
* @css: target css
|
|
|
|
*
|
|
|
|
* Obtain a reference on @css unless it already has reached zero and is
|
|
|
|
* being released. This function doesn't care whether @css is on or
|
|
|
|
* offline. The caller naturally needs to ensure that @css is accessible
|
|
|
|
* but doesn't have to be holding a reference on it - IOW, RCU protected
|
|
|
|
* access is good enough for this function. Returns %true if a reference
|
|
|
|
* count was successfully obtained; %false otherwise.
|
|
|
|
*/
|
|
|
|
static inline bool css_tryget(struct cgroup_subsys_state *css)
|
|
|
|
{
|
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
return percpu_ref_tryget(&css->refcnt);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-06-13 12:04:52 +08:00
|
|
|
/**
|
2014-05-14 00:11:01 +08:00
|
|
|
* css_tryget_online - try to obtain a reference on the specified css if online
|
2013-06-13 12:04:52 +08:00
|
|
|
* @css: target css
|
|
|
|
*
|
2014-05-14 00:11:01 +08:00
|
|
|
* Obtain a reference on @css if it's online. The caller naturally needs
|
|
|
|
* to ensure that @css is accessible but doesn't have to be holding a
|
2013-06-13 12:04:52 +08:00
|
|
|
* reference on it - IOW, RCU protected access is good enough for this
|
|
|
|
* function. Returns %true if a reference count was successfully obtained;
|
|
|
|
* %false otherwise.
|
|
|
|
*/
|
2014-05-14 00:11:01 +08:00
|
|
|
static inline bool css_tryget_online(struct cgroup_subsys_state *css)
|
2009-01-08 10:08:38 +08:00
|
|
|
{
|
2014-05-17 01:22:47 +08:00
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
return percpu_ref_tryget_live(&css->refcnt);
|
|
|
|
return true;
|
2009-01-08 10:08:38 +08:00
|
|
|
}
|
2011-12-13 10:12:21 +08:00
|
|
|
|
2017-05-25 00:03:48 +08:00
|
|
|
/**
|
|
|
|
* css_is_dying - test whether the specified css is dying
|
|
|
|
* @css: target css
|
|
|
|
*
|
|
|
|
* Test whether @css is in the process of offlining or already offline. In
|
|
|
|
* most cases, ->css_online() and ->css_offline() callbacks should be
|
|
|
|
* enough; however, the actual offline operations are RCU delayed and this
|
|
|
|
* test returns %true also when @css is scheduled to be offlined.
|
|
|
|
*
|
|
|
|
* This is useful, for example, when the use case requires synchronous
|
|
|
|
* behavior with respect to cgroup removal. cgroup removal schedules css
|
|
|
|
* offlining but the css can seem alive while the operation is being
|
|
|
|
* delayed. If the delay affects user visible semantics, this test can be
|
|
|
|
* used to resolve the situation.
|
|
|
|
*/
|
|
|
|
static inline bool css_is_dying(struct cgroup_subsys_state *css)
|
|
|
|
{
|
|
|
|
return !(css->flags & CSS_NO_REF) && percpu_ref_is_dying(&css->refcnt);
|
|
|
|
}
|
|
|
|
|
2011-12-13 10:12:21 +08:00
|
|
|
/**
|
2013-06-13 12:04:52 +08:00
|
|
|
* css_put - put a css reference
|
|
|
|
* @css: target css
|
|
|
|
*
|
2014-05-14 00:11:01 +08:00
|
|
|
* Put a reference obtained via css_get() and css_tryget_online().
|
2011-12-13 10:12:21 +08:00
|
|
|
*/
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
static inline void css_put(struct cgroup_subsys_state *css)
|
|
|
|
{
|
2014-05-17 01:22:47 +08:00
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
percpu_ref_put(&css->refcnt);
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
}
|
2011-12-13 10:12:21 +08:00
|
|
|
|
2014-12-11 07:42:42 +08:00
|
|
|
/**
|
|
|
|
* css_put_many - put css references
|
|
|
|
* @css: target css
|
|
|
|
* @n: number of references to put
|
|
|
|
*
|
|
|
|
* Put references obtained via css_get() and css_tryget_online().
|
2009-02-04 17:12:08 +08:00
|
|
|
*/
|
2014-12-11 07:42:42 +08:00
|
|
|
static inline void css_put_many(struct cgroup_subsys_state *css, unsigned int n)
|
|
|
|
{
|
|
|
|
if (!(css->flags & CSS_NO_REF))
|
|
|
|
percpu_ref_put_many(&css->refcnt, n);
|
|
|
|
}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-11-21 04:55:52 +08:00
|
|
|
static inline void cgroup_put(struct cgroup *cgrp)
|
|
|
|
{
|
|
|
|
css_put(&cgrp->self);
|
|
|
|
}
|
|
|
|
|
2013-06-26 02:48:32 +08:00
|
|
|
/**
|
|
|
|
* task_css_set_check - obtain a task's css_set with extra access conditions
|
|
|
|
* @task: the task to obtain css_set for
|
|
|
|
* @__c: extra condition expression to be passed to rcu_dereference_check()
|
|
|
|
*
|
|
|
|
* A task's css_set is RCU protected, initialized and exited while holding
|
|
|
|
* task_lock(), and can only be modified while holding both cgroup_mutex
|
|
|
|
* and task_lock() while the task is alive. This macro verifies that the
|
|
|
|
* caller is inside proper critical section and returns @task's css_set.
|
|
|
|
*
|
|
|
|
* The caller can also specify additional allowed conditions via @__c, such
|
|
|
|
* as locks used during the cgroup_subsys::attach() methods.
|
2010-06-08 17:40:42 +08:00
|
|
|
*/
|
2013-04-08 00:29:51 +08:00
|
|
|
#ifdef CONFIG_PROVE_RCU
|
|
|
|
extern struct mutex cgroup_mutex;
|
2015-10-16 04:41:53 +08:00
|
|
|
extern spinlock_t css_set_lock;
|
2013-06-26 02:48:32 +08:00
|
|
|
#define task_css_set_check(task, __c) \
|
|
|
|
rcu_dereference_check((task)->cgroups, \
|
2014-02-25 23:04:03 +08:00
|
|
|
lockdep_is_held(&cgroup_mutex) || \
|
2015-10-16 04:41:53 +08:00
|
|
|
lockdep_is_held(&css_set_lock) || \
|
2014-02-25 23:04:03 +08:00
|
|
|
((task)->flags & PF_EXITING) || (__c))
|
2013-04-08 00:29:51 +08:00
|
|
|
#else
|
2013-06-26 02:48:32 +08:00
|
|
|
#define task_css_set_check(task, __c) \
|
|
|
|
rcu_dereference((task)->cgroups)
|
2013-04-08 00:29:51 +08:00
|
|
|
#endif
|
2010-06-08 17:40:42 +08:00
|
|
|
|
2013-06-26 02:48:32 +08:00
|
|
|
/**
|
2013-08-09 08:11:22 +08:00
|
|
|
* task_css_check - obtain css for (task, subsys) w/ extra access conds
|
2013-06-26 02:48:32 +08:00
|
|
|
* @task: the target task
|
|
|
|
* @subsys_id: the target subsystem ID
|
|
|
|
* @__c: extra condition expression to be passed to rcu_dereference_check()
|
|
|
|
*
|
|
|
|
* Return the cgroup_subsys_state for the (@task, @subsys_id) pair. The
|
|
|
|
* synchronization rules are the same as task_css_set_check().
|
|
|
|
*/
|
2013-08-09 08:11:22 +08:00
|
|
|
#define task_css_check(task, subsys_id, __c) \
|
2013-06-26 02:48:32 +08:00
|
|
|
task_css_set_check((task), (__c))->subsys[(subsys_id)]
|
|
|
|
|
|
|
|
/**
|
|
|
|
* task_css_set - obtain a task's css_set
|
|
|
|
* @task: the task to obtain css_set for
|
|
|
|
*
|
|
|
|
* See task_css_set_check().
|
|
|
|
*/
|
|
|
|
static inline struct css_set *task_css_set(struct task_struct *task)
|
|
|
|
{
|
|
|
|
return task_css_set_check(task, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2013-08-09 08:11:22 +08:00
|
|
|
* task_css - obtain css for (task, subsys)
|
2013-06-26 02:48:32 +08:00
|
|
|
* @task: the target task
|
|
|
|
* @subsys_id: the target subsystem ID
|
|
|
|
*
|
2013-08-09 08:11:22 +08:00
|
|
|
* See task_css_check().
|
2013-06-26 02:48:32 +08:00
|
|
|
*/
|
2013-08-09 08:11:22 +08:00
|
|
|
static inline struct cgroup_subsys_state *task_css(struct task_struct *task,
|
|
|
|
int subsys_id)
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
{
|
2013-08-09 08:11:22 +08:00
|
|
|
return task_css_check(task, subsys_id, false);
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
}
|
|
|
|
|
2015-05-23 05:13:22 +08:00
|
|
|
/**
|
|
|
|
* task_get_css - find and get the css for (task, subsys)
|
|
|
|
* @task: the target task
|
|
|
|
* @subsys_id: the target subsystem ID
|
|
|
|
*
|
|
|
|
* Find the css for the (@task, @subsys_id) combination, increment a
|
|
|
|
* reference on and return it. This function is guaranteed to return a
|
|
|
|
* valid css.
|
|
|
|
*/
|
|
|
|
static inline struct cgroup_subsys_state *
|
|
|
|
task_get_css(struct task_struct *task, int subsys_id)
|
|
|
|
{
|
|
|
|
struct cgroup_subsys_state *css;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
while (true) {
|
|
|
|
css = task_css(task, subsys_id);
|
|
|
|
if (likely(css_tryget_online(css)))
|
|
|
|
break;
|
|
|
|
cpu_relax();
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return css;
|
|
|
|
}
|
|
|
|
|
2014-05-08 09:31:17 +08:00
|
|
|
/**
|
|
|
|
* task_css_is_root - test whether a task belongs to the root css
|
|
|
|
* @task: the target task
|
|
|
|
* @subsys_id: the target subsystem ID
|
|
|
|
*
|
|
|
|
* Test whether @task belongs to the root css on the specified subsystem.
|
|
|
|
* May be invoked in any context.
|
|
|
|
*/
|
|
|
|
static inline bool task_css_is_root(struct task_struct *task, int subsys_id)
|
|
|
|
{
|
|
|
|
return task_css_check(task, subsys_id, true) ==
|
|
|
|
init_css_set.subsys[subsys_id];
|
|
|
|
}
|
|
|
|
|
2013-08-09 08:11:22 +08:00
|
|
|
static inline struct cgroup *task_cgroup(struct task_struct *task,
|
|
|
|
int subsys_id)
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
{
|
2013-08-09 08:11:22 +08:00
|
|
|
return task_css(task, subsys_id)->cgroup;
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
}
|
|
|
|
|
2015-11-21 04:55:52 +08:00
|
|
|
/**
|
|
|
|
* cgroup_is_descendant - test ancestry
|
|
|
|
* @cgrp: the cgroup to be tested
|
|
|
|
* @ancestor: possible ancestor of @cgrp
|
|
|
|
*
|
|
|
|
* Test whether @cgrp is a descendant of @ancestor. It also returns %true
|
|
|
|
* if @cgrp == @ancestor. This function is safe to call as long as @cgrp
|
|
|
|
* and @ancestor are accessible.
|
|
|
|
*/
|
|
|
|
static inline bool cgroup_is_descendant(struct cgroup *cgrp,
|
|
|
|
struct cgroup *ancestor)
|
|
|
|
{
|
|
|
|
if (cgrp->root != ancestor->root || cgrp->level < ancestor->level)
|
|
|
|
return false;
|
|
|
|
return cgrp->ancestor_ids[ancestor->level] == ancestor->id;
|
|
|
|
}
|
|
|
|
|
2016-08-12 23:56:40 +08:00
|
|
|
/**
|
|
|
|
* task_under_cgroup_hierarchy - test task's membership of cgroup ancestry
|
|
|
|
* @task: the task to be tested
|
|
|
|
* @ancestor: possible ancestor of @task's cgroup
|
|
|
|
*
|
|
|
|
* Tests whether @task's default cgroup hierarchy is a descendant of @ancestor.
|
|
|
|
* It follows all the same rules as cgroup_is_descendant, and only applies
|
|
|
|
* to the default hierarchy.
|
|
|
|
*/
|
|
|
|
static inline bool task_under_cgroup_hierarchy(struct task_struct *task,
|
|
|
|
struct cgroup *ancestor)
|
|
|
|
{
|
|
|
|
struct css_set *cset = task_css_set(task);
|
|
|
|
|
|
|
|
return cgroup_is_descendant(cset->dfl_cgrp, ancestor);
|
|
|
|
}
|
|
|
|
|
2014-02-13 19:58:39 +08:00
|
|
|
/* no synchronization, the result can only be used as a hint */
|
2015-10-16 04:41:50 +08:00
|
|
|
static inline bool cgroup_is_populated(struct cgroup *cgrp)
|
2014-02-13 19:58:39 +08:00
|
|
|
{
|
2015-10-16 04:41:50 +08:00
|
|
|
return cgrp->populated_cnt;
|
2014-02-13 19:58:39 +08:00
|
|
|
}
|
2014-05-17 01:22:52 +08:00
|
|
|
|
2014-09-19 16:29:31 +08:00
|
|
|
/* returns ino associated with a cgroup */
|
2014-02-12 00:52:49 +08:00
|
|
|
static inline ino_t cgroup_ino(struct cgroup *cgrp)
|
|
|
|
{
|
2017-07-13 02:49:50 +08:00
|
|
|
return cgrp->kn->id.ino;
|
2014-02-12 00:52:49 +08:00
|
|
|
}
|
2014-04-23 23:13:15 +08:00
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
/* cft/css accessors for cftype->write() operation */
|
|
|
|
static inline struct cftype *of_cft(struct kernfs_open_file *of)
|
2013-12-06 01:28:04 +08:00
|
|
|
{
|
cgroup: convert to kernfs
cgroup filesystem code was derived from the original sysfs
implementation which was heavily intertwined with vfs objects and
locking with the goal of re-using the existing vfs infrastructure.
That experiment turned out rather disastrous and sysfs switched, a
long time ago, to distributed filesystem model where a separate
representation is maintained which is queried by vfs. Unfortunately,
cgroup stuck with the failed experiment all these years and
accumulated even more problems over time.
Locking and object lifetime management being entangled with vfs is
probably the most egregious. vfs is never designed to be misused like
this and cgroup ends up jumping through various convoluted dancing to
make things work. Even then, operations across multiple cgroups can't
be done safely as it'll deadlock with rename locking.
Recently, kernfs is separated out from sysfs so that it can be used by
users other than sysfs. This patch converts cgroup to use kernfs,
which will bring the following benefits.
* Separation from vfs internals. Locking and object lifetime
management is contained in cgroup proper making things a lot
simpler. This removes significant amount of locking convolutions,
hairy object lifetime rules and the restriction on multi-cgroup
operations.
* Can drop a lot of code to implement filesystem interface as most are
provided by kernfs.
* Proper "severing" semantics, which allows controllers to not worry
about lingering file accesses after offline.
While the preceding patches did as much as possible to make the
transition less painful, large part of the conversion has to be one
discrete step making this patch rather large. The rest of the commit
message lists notable changes in different areas.
Overall
-------
* vfs constructs replaced with kernfs ones. cgroup->dentry w/ ->kn,
cgroupfs_root->sb w/ ->kf_root.
* All dentry accessors are removed. Helpers to map from kernfs
constructs are added.
* All vfs plumbing around dentry, inode and bdi removed.
* cgroup_mount() now directly looks for matching root and then
proceeds to create a new one if not found.
Synchronization and object lifetime
-----------------------------------
* vfs inode locking removed. Among other things, this removes the
need for the convolution in cgroup_cfts_commit(). Future patches
will further simplify it.
* vfs refcnting replaced with cgroup internal ones. cgroup->refcnt,
cgroupfs_root->refcnt added. cgroup_put_root() now directly puts
root->refcnt and when it reaches zero proceeds to destroy it thus
merging cgroup_put_root() and the former cgroup_kill_sb().
Simliarly, cgroup_put() now directly schedules cgroup_free_rcu()
when refcnt reaches zero.
* Unlike before, kernfs objects don't hold onto cgroup objects. When
cgroup destroys a kernfs node, all existing operations are drained
and the association is broken immediately. The same for
cgroupfs_roots and mounts.
* All operations which come through kernfs guarantee that the
associated cgroup is and stays valid for the duration of operation;
however, there are two paths which need to find out the associated
cgroup from dentry without going through kernfs -
css_tryget_from_dir() and cgroupstats_build(). For these two,
kernfs_node->priv is RCU managed so that they can dereference it
under RCU read lock.
File and directory handling
---------------------------
* File and directory operations converted to kernfs_ops and
kernfs_syscall_ops.
* xattrs is implicitly supported by kernfs. No need to worry about it
from cgroup. This means that "xattr" mount option is no longer
necessary. A future patch will add a deprecated warning message
when sane_behavior.
* When cftype->max_write_len > PAGE_SIZE, it's necessary to make a
private copy of one of the kernfs_ops to set its atomic_write_len.
cftype->kf_ops is added and cgroup_init/exit_cftypes() are updated
to handle it.
* cftype->lockdep_key added so that kernfs lockdep annotation can be
per cftype.
* Inidividual file entries and open states are now managed by kernfs.
No need to worry about them from cgroup. cfent, cgroup_open_file
and their friends are removed.
* kernfs_nodes are created deactivated and kernfs_activate()
invocations added to places where creation of new nodes are
committed.
* cgroup_rmdir() uses kernfs_[un]break_active_protection() for
self-removal.
v2: - Li pointed out in an earlier patch that specifying "name="
during mount without subsystem specification should succeed if
there's an existing hierarchy with a matching name although it
should fail with -EINVAL if a new hierarchy should be created.
Prior to the conversion, this used by handled by deferring
failure from NULL return from cgroup_root_from_opts(), which was
necessary because root was being created before checking for
existing ones. Note that cgroup_root_from_opts() returned an
ERR_PTR() value for error conditions which require immediate
mount failure.
As we now have separate search and creation steps, deferring
failure from cgroup_root_from_opts() is no longer necessary.
cgroup_root_from_opts() is updated to always return ERR_PTR()
value on failure.
- The logic to match existing roots is updated so that a mount
attempt with a matching name but different subsys_mask are
rejected. This was handled by a separate matching loop under
the comment "Check for name clashes with existing mounts" but
got lost during conversion. Merge the check into the main
search loop.
- Add __rcu __force casting in RCU_INIT_POINTER() in
cgroup_destroy_locked() to avoid the sparse address space
warning reported by kbuild test bot. Maybe we want an explicit
interface to use kn->priv as RCU protected pointer?
v3: Make CONFIG_CGROUPS select CONFIG_KERNFS.
v4: Rebased on top of 0ab02ca8f887 ("cgroup: protect modifications to
cgroup_idr with cgroup_mutex").
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: kbuild test robot fengguang.wu@intel.com>
2014-02-12 00:52:49 +08:00
|
|
|
return of->kn->priv;
|
2013-12-06 01:28:04 +08:00
|
|
|
}
|
2014-04-23 23:13:15 +08:00
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
struct cgroup_subsys_state *of_css(struct kernfs_open_file *of);
|
2007-10-19 14:39:36 +08:00
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
/* cft/css accessors for cftype->seq_*() operations */
|
|
|
|
static inline struct cftype *seq_cft(struct seq_file *seq)
|
|
|
|
{
|
|
|
|
return of_cft(seq->private);
|
|
|
|
}
|
2013-08-09 08:11:26 +08:00
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
static inline struct cgroup_subsys_state *seq_css(struct seq_file *seq)
|
|
|
|
{
|
|
|
|
return of_css(seq->private);
|
|
|
|
}
|
2010-09-10 07:37:37 +08:00
|
|
|
|
2014-02-12 22:29:50 +08:00
|
|
|
/*
|
|
|
|
* Name / path handling functions. All are thin wrappers around the kernfs
|
|
|
|
* counterparts and can be called under any context.
|
|
|
|
*/
|
cgroup: CSS ID support
Patch for Per-CSS(Cgroup Subsys State) ID and private hierarchy code.
This patch attaches unique ID to each css and provides following.
- css_lookup(subsys, id)
returns pointer to struct cgroup_subysys_state of id.
- css_get_next(subsys, id, rootid, depth, foundid)
returns the next css under "root" by scanning
When cgroup_subsys->use_id is set, an id for css is maintained.
The cgroup framework only parepares
- css_id of root css for subsys
- id is automatically attached at creation of css.
- id is *not* freed automatically. Because the cgroup framework
don't know lifetime of cgroup_subsys_state.
free_css_id() function is provided. This must be called by subsys.
There are several reasons to develop this.
- Saving space .... For example, memcg's swap_cgroup is array of
pointers to cgroup. But it is not necessary to be very fast.
By replacing pointers(8bytes per ent) to ID (2byes per ent), we can
reduce much amount of memory usage.
- Scanning without lock.
CSS_ID provides "scan id under this ROOT" function. By this, scanning
css under root can be written without locks.
ex)
do {
rcu_read_lock();
next = cgroup_get_next(subsys, id, root, &found);
/* check sanity of next here */
css_tryget();
rcu_read_unlock();
id = found + 1
} while(...)
Characteristics:
- Each css has unique ID under subsys.
- Lifetime of ID is controlled by subsys.
- css ID contains "ID" and "Depth in hierarchy" and stack of hierarchy
- Allowed ID is 1-65535, ID 0 is UNUSED ID.
Design Choices:
- scan-by-ID v.s. scan-by-tree-walk.
As /proc's pid scan does, scan-by-ID is robust when scanning is done
by following kind of routine.
scan -> rest a while(release a lock) -> conitunue from interrupted
memcg's hierarchical reclaim does this.
- When subsys->use_id is set, # of css in the system is limited to
65535.
[bharata@linux.vnet.ibm.com: remove rcu_read_lock() from css_get_next()]
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Paul Menage <menage@google.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-03 07:57:25 +08:00
|
|
|
|
2014-02-12 22:29:50 +08:00
|
|
|
static inline int cgroup_name(struct cgroup *cgrp, char *buf, size_t buflen)
|
|
|
|
{
|
2014-03-19 22:23:54 +08:00
|
|
|
return kernfs_name(cgrp->kn, buf, buflen);
|
2014-02-12 22:29:50 +08:00
|
|
|
}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2016-08-10 23:23:44 +08:00
|
|
|
static inline int cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen)
|
2014-02-12 22:29:50 +08:00
|
|
|
{
|
2014-03-19 22:23:54 +08:00
|
|
|
return kernfs_path(cgrp->kn, buf, buflen);
|
2014-02-12 22:29:50 +08:00
|
|
|
}
|
2015-01-07 01:02:46 +08:00
|
|
|
|
2014-02-12 22:29:50 +08:00
|
|
|
static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
|
|
|
|
{
|
2014-03-19 22:23:54 +08:00
|
|
|
pr_cont_kernfs_name(cgrp->kn);
|
2014-02-12 22:29:50 +08:00
|
|
|
}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2014-02-12 22:29:50 +08:00
|
|
|
static inline void pr_cont_cgroup_path(struct cgroup *cgrp)
|
Add cgroupstats
This patch is inspired by the discussion at
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
as suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263. The
patch is on top of 2.6.21-mm1 with Paul's cgroups v9 patches (forward
ported)
This patch implements per cgroup statistics infrastructure and re-uses
code from the taskstats interface. A new set of cgroup operations are
registered with commands and attributes. It should be very easy to
*extend* per cgroup statistics, by adding members to the cgroupstats
structure.
The current model for cgroupstats is a pull, a push model (to post
statistics on interesting events), should be very easy to add. Currently
user space requests for statistics by passing the cgroup file
descriptor. Statistics about the state of all the tasks in the cgroup
is returned to user space.
TODO's/NOTE:
This patch provides an infrastructure for implementing cgroup statistics.
Based on the needs of each controller, we can incrementally add more statistics,
event based support for notification of statistics, accumulation of taskstats
into cgroup statistics in the future.
Sample output
# ./cgroupstats -C /cgroup/a
sleeping 2, blocked 0, running 1, stopped 0, uninterruptible 0
# ./cgroupstats -C /cgroup/
sleeping 154, blocked 0, running 0, stopped 0, uninterruptible 0
If the approach looks good, I'll enhance and post the user space utility for
the same
Feedback, comments, test results are always welcome!
[akpm@linux-foundation.org: build fix]
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Jay Lan <jlan@engr.sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:44 +08:00
|
|
|
{
|
2014-03-19 22:23:54 +08:00
|
|
|
pr_cont_kernfs_path(cgrp->kn);
|
Add cgroupstats
This patch is inspired by the discussion at
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
as suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263. The
patch is on top of 2.6.21-mm1 with Paul's cgroups v9 patches (forward
ported)
This patch implements per cgroup statistics infrastructure and re-uses
code from the taskstats interface. A new set of cgroup operations are
registered with commands and attributes. It should be very easy to
*extend* per cgroup statistics, by adding members to the cgroupstats
structure.
The current model for cgroupstats is a pull, a push model (to post
statistics on interesting events), should be very easy to add. Currently
user space requests for statistics by passing the cgroup file
descriptor. Statistics about the state of all the tasks in the cgroup
is returned to user space.
TODO's/NOTE:
This patch provides an infrastructure for implementing cgroup statistics.
Based on the needs of each controller, we can incrementally add more statistics,
event based support for notification of statistics, accumulation of taskstats
into cgroup statistics in the future.
Sample output
# ./cgroupstats -C /cgroup/a
sleeping 2, blocked 0, running 1, stopped 0, uninterruptible 0
# ./cgroupstats -C /cgroup/
sleeping 154, blocked 0, running 0, stopped 0, uninterruptible 0
If the approach looks good, I'll enhance and post the user space utility for
the same
Feedback, comments, test results are always welcome!
[akpm@linux-foundation.org: build fix]
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Jay Lan <jlan@engr.sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:44 +08:00
|
|
|
}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
cgroup, kthread: close race window where new kthreads can be migrated to non-root cgroups
Creation of a kthread goes through a couple interlocked stages between
the kthread itself and its creator. Once the new kthread starts
running, it initializes itself and wakes up the creator. The creator
then can further configure the kthread and then let it start doing its
job by waking it up.
In this configuration-by-creator stage, the creator is the only one
that can wake it up but the kthread is visible to userland. When
altering the kthread's attributes from userland is allowed, this is
fine; however, for cases where CPU affinity is critical,
kthread_bind() is used to first disable affinity changes from userland
and then set the affinity. This also prevents the kthread from being
migrated into non-root cgroups as that can affect the CPU affinity and
many other things.
Unfortunately, the cgroup side of protection is racy. While the
PF_NO_SETAFFINITY flag prevents further migrations, userland can win
the race before the creator sets the flag with kthread_bind() and put
the kthread in a non-root cgroup, which can lead to all sorts of
problems including incorrect CPU affinity and starvation.
This bug got triggered by userland which periodically tries to migrate
all processes in the root cpuset cgroup to a non-root one. Per-cpu
workqueue workers got caught while being created and ended up with
incorrected CPU affinity breaking concurrency management and sometimes
stalling workqueue execution.
This patch adds task->no_cgroup_migration which disallows the task to
be migrated by userland. kthreadd starts with the flag set making
every child kthread start in the root cgroup with migration
disallowed. The flag is cleared after the kthread finishes
initialization by which time PF_NO_SETAFFINITY is set if the kthread
should stay in the root cgroup.
It'd be better to wait for the initialization instead of failing but I
couldn't think of a way of implementing that without adding either a
new PF flag, or sleeping and retrying from waiting side. Even if
userland depends on changing cgroup membership of a kthread, it either
has to be synchronized with kthread_create() or periodically repeat,
so it's unlikely that this would break anything.
v2: Switch to a simpler implementation using a new task_struct bit
field suggested by Oleg.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-and-debugged-by: Chris Mason <clm@fb.com>
Cc: stable@vger.kernel.org # v4.3+ (we can't close the race on < v4.3)
Signed-off-by: Tejun Heo <tj@kernel.org>
2017-03-17 04:54:24 +08:00
|
|
|
static inline void cgroup_init_kthreadd(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* kthreadd is inherited by all kthreads, keep it in the root so
|
|
|
|
* that the new kthreads are guaranteed to stay in the root until
|
|
|
|
* initialization is finished.
|
|
|
|
*/
|
|
|
|
current->no_cgroup_migration = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void cgroup_kthread_ready(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This kthread finished initialization. The creator should have
|
|
|
|
* set PF_NO_SETAFFINITY if this kthread should stay in the root.
|
|
|
|
*/
|
|
|
|
current->no_cgroup_migration = 0;
|
|
|
|
}
|
|
|
|
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
#else /* !CONFIG_CGROUPS */
|
|
|
|
|
2015-01-07 01:02:46 +08:00
|
|
|
struct cgroup_subsys_state;
|
2016-08-12 23:56:40 +08:00
|
|
|
struct cgroup;
|
2015-01-07 01:02:46 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
static inline void css_put(struct cgroup_subsys_state *css) {}
|
2010-09-10 07:37:37 +08:00
|
|
|
static inline int cgroup_attach_task_all(struct task_struct *from,
|
2015-05-14 04:24:16 +08:00
|
|
|
struct task_struct *t) { return 0; }
|
|
|
|
static inline int cgroupstats_build(struct cgroupstats *stats,
|
|
|
|
struct dentry *dentry) { return -EINVAL; }
|
|
|
|
|
2007-10-19 14:39:33 +08:00
|
|
|
static inline void cgroup_fork(struct task_struct *p) {}
|
2015-12-03 23:24:08 +08:00
|
|
|
static inline int cgroup_can_fork(struct task_struct *p) { return 0; }
|
|
|
|
static inline void cgroup_cancel_fork(struct task_struct *p) {}
|
|
|
|
static inline void cgroup_post_fork(struct task_struct *p) {}
|
2014-03-28 15:22:19 +08:00
|
|
|
static inline void cgroup_exit(struct task_struct *p) {}
|
2015-10-16 04:41:53 +08:00
|
|
|
static inline void cgroup_free(struct task_struct *p) {}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
|
2015-05-14 04:24:16 +08:00
|
|
|
static inline int cgroup_init_early(void) { return 0; }
|
|
|
|
static inline int cgroup_init(void) { return 0; }
|
cgroup, kthread: close race window where new kthreads can be migrated to non-root cgroups
Creation of a kthread goes through a couple interlocked stages between
the kthread itself and its creator. Once the new kthread starts
running, it initializes itself and wakes up the creator. The creator
then can further configure the kthread and then let it start doing its
job by waking it up.
In this configuration-by-creator stage, the creator is the only one
that can wake it up but the kthread is visible to userland. When
altering the kthread's attributes from userland is allowed, this is
fine; however, for cases where CPU affinity is critical,
kthread_bind() is used to first disable affinity changes from userland
and then set the affinity. This also prevents the kthread from being
migrated into non-root cgroups as that can affect the CPU affinity and
many other things.
Unfortunately, the cgroup side of protection is racy. While the
PF_NO_SETAFFINITY flag prevents further migrations, userland can win
the race before the creator sets the flag with kthread_bind() and put
the kthread in a non-root cgroup, which can lead to all sorts of
problems including incorrect CPU affinity and starvation.
This bug got triggered by userland which periodically tries to migrate
all processes in the root cpuset cgroup to a non-root one. Per-cpu
workqueue workers got caught while being created and ended up with
incorrected CPU affinity breaking concurrency management and sometimes
stalling workqueue execution.
This patch adds task->no_cgroup_migration which disallows the task to
be migrated by userland. kthreadd starts with the flag set making
every child kthread start in the root cgroup with migration
disallowed. The flag is cleared after the kthread finishes
initialization by which time PF_NO_SETAFFINITY is set if the kthread
should stay in the root cgroup.
It'd be better to wait for the initialization instead of failing but I
couldn't think of a way of implementing that without adding either a
new PF flag, or sleeping and retrying from waiting side. Even if
userland depends on changing cgroup membership of a kthread, it either
has to be synchronized with kthread_create() or periodically repeat,
so it's unlikely that this would break anything.
v2: Switch to a simpler implementation using a new task_struct bit
field suggested by Oleg.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-and-debugged-by: Chris Mason <clm@fb.com>
Cc: stable@vger.kernel.org # v4.3+ (we can't close the race on < v4.3)
Signed-off-by: Tejun Heo <tj@kernel.org>
2017-03-17 04:54:24 +08:00
|
|
|
static inline void cgroup_init_kthreadd(void) {}
|
|
|
|
static inline void cgroup_kthread_ready(void) {}
|
2010-05-31 04:24:39 +08:00
|
|
|
|
2016-08-12 23:56:40 +08:00
|
|
|
static inline bool task_under_cgroup_hierarchy(struct task_struct *task,
|
|
|
|
struct cgroup *ancestor)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
#endif /* !CONFIG_CGROUPS */
|
|
|
|
|
sock, cgroup: add sock->sk_cgroup
In cgroup v1, dealing with cgroup membership was difficult because the
number of membership associations was unbound. As a result, cgroup v1
grew several controllers whose primary purpose is either tagging
membership or pull in configuration knobs from other subsystems so
that cgroup membership test can be avoided.
net_cls and net_prio controllers are examples of the latter. They
allow configuring network-specific attributes from cgroup side so that
network subsystem can avoid testing cgroup membership; unfortunately,
these are not only cumbersome but also problematic.
Both net_cls and net_prio aren't properly hierarchical. Both inherit
configuration from the parent on creation but there's no interaction
afterwards. An ancestor doesn't restrict the behavior in its subtree
in anyway and configuration changes aren't propagated downwards.
Especially when combined with cgroup delegation, this is problematic
because delegatees can mess up whatever network configuration
implemented at the system level. net_prio would allow the delegatees
to set whatever priority value regardless of CAP_NET_ADMIN and net_cls
the same for classid.
While it is possible to solve these issues from controller side by
implementing hierarchical allowable ranges in both controllers, it
would involve quite a bit of complexity in the controllers and further
obfuscate network configuration as it becomes even more difficult to
tell what's actually being configured looking from the network side.
While not much can be done for v1 at this point, as membership
handling is sane on cgroup v2, it'd be better to make cgroup matching
behave like other network matches and classifiers than introducing
further complications.
In preparation, this patch updates sock->sk_cgrp_data handling so that
it points to the v2 cgroup that sock was created in until either
net_prio or net_cls is used. Once either of the two is used,
sock->sk_cgrp_data reverts to its previous role of carrying prioidx
and classid. This is to avoid adding yet another cgroup related field
to struct sock.
As the mode switching can happen at most once per boot, the switching
mechanism is aimed at lowering hot path overhead. It may leak a
finite, likely small, number of cgroup refs and report spurious
prioidx or classid on switching; however, dynamic updates of prioidx
and classid have always been racy and lossy - socks between creation
and fd installation are never updated, config changes don't update
existing sockets at all, and prioidx may index with dead and recycled
cgroup IDs. Non-critical inaccuracies from small race windows won't
make any noticeable difference.
This patch doesn't make use of the pointer yet. The following patch
will implement netfilter match for cgroup2 membership.
v2: Use sock_cgroup_data to avoid inflating struct sock w/ another
cgroup specific field.
v3: Add comments explaining why sock_data_prioidx() and
sock_data_classid() use different fallback values.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Daniel Wagner <daniel.wagner@bmw-carit.de>
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-08 06:38:53 +08:00
|
|
|
/*
|
|
|
|
* sock->sk_cgrp_data handling. For more info, see sock_cgroup_data
|
|
|
|
* definition in cgroup-defs.h.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_SOCK_CGROUP_DATA
|
|
|
|
|
|
|
|
#if defined(CONFIG_CGROUP_NET_PRIO) || defined(CONFIG_CGROUP_NET_CLASSID)
|
|
|
|
extern spinlock_t cgroup_sk_update_lock;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
void cgroup_sk_alloc_disable(void);
|
|
|
|
void cgroup_sk_alloc(struct sock_cgroup_data *skcd);
|
|
|
|
void cgroup_sk_free(struct sock_cgroup_data *skcd);
|
|
|
|
|
|
|
|
static inline struct cgroup *sock_cgroup_ptr(struct sock_cgroup_data *skcd)
|
|
|
|
{
|
|
|
|
#if defined(CONFIG_CGROUP_NET_PRIO) || defined(CONFIG_CGROUP_NET_CLASSID)
|
|
|
|
unsigned long v;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* @skcd->val is 64bit but the following is safe on 32bit too as we
|
|
|
|
* just need the lower ulong to be written and read atomically.
|
|
|
|
*/
|
|
|
|
v = READ_ONCE(skcd->val);
|
|
|
|
|
|
|
|
if (v & 1)
|
|
|
|
return &cgrp_dfl_root.cgrp;
|
|
|
|
|
|
|
|
return (struct cgroup *)(unsigned long)v ?: &cgrp_dfl_root.cgrp;
|
|
|
|
#else
|
|
|
|
return (struct cgroup *)(unsigned long)skcd->val;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_CGROUP_DATA */
|
|
|
|
|
|
|
|
static inline void cgroup_sk_alloc(struct sock_cgroup_data *skcd) {}
|
|
|
|
static inline void cgroup_sk_free(struct sock_cgroup_data *skcd) {}
|
|
|
|
|
|
|
|
#endif /* CONFIG_CGROUP_DATA */
|
|
|
|
|
2016-01-29 16:54:06 +08:00
|
|
|
struct cgroup_namespace {
|
2017-02-20 18:19:00 +08:00
|
|
|
refcount_t count;
|
2016-01-29 16:54:06 +08:00
|
|
|
struct ns_common ns;
|
|
|
|
struct user_namespace *user_ns;
|
2016-08-09 03:25:30 +08:00
|
|
|
struct ucounts *ucounts;
|
2016-01-29 16:54:06 +08:00
|
|
|
struct css_set *root_cset;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct cgroup_namespace init_cgroup_ns;
|
|
|
|
|
|
|
|
#ifdef CONFIG_CGROUPS
|
|
|
|
|
|
|
|
void free_cgroup_ns(struct cgroup_namespace *ns);
|
|
|
|
|
|
|
|
struct cgroup_namespace *copy_cgroup_ns(unsigned long flags,
|
|
|
|
struct user_namespace *user_ns,
|
|
|
|
struct cgroup_namespace *old_ns);
|
|
|
|
|
2016-08-10 23:23:44 +08:00
|
|
|
int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
|
|
|
|
struct cgroup_namespace *ns);
|
2016-01-29 16:54:06 +08:00
|
|
|
|
|
|
|
#else /* !CONFIG_CGROUPS */
|
|
|
|
|
|
|
|
static inline void free_cgroup_ns(struct cgroup_namespace *ns) { }
|
|
|
|
static inline struct cgroup_namespace *
|
|
|
|
copy_cgroup_ns(unsigned long flags, struct user_namespace *user_ns,
|
|
|
|
struct cgroup_namespace *old_ns)
|
|
|
|
{
|
|
|
|
return old_ns;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_CGROUPS */
|
|
|
|
|
|
|
|
static inline void get_cgroup_ns(struct cgroup_namespace *ns)
|
|
|
|
{
|
|
|
|
if (ns)
|
2017-02-20 18:19:00 +08:00
|
|
|
refcount_inc(&ns->count);
|
2016-01-29 16:54:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void put_cgroup_ns(struct cgroup_namespace *ns)
|
|
|
|
{
|
2017-02-20 18:19:00 +08:00
|
|
|
if (ns && refcount_dec_and_test(&ns->count))
|
2016-01-29 16:54:06 +08:00
|
|
|
free_cgroup_ns(ns);
|
|
|
|
}
|
|
|
|
|
Task Control Groups: basic task cgroup framework
Generic Process Control Groups
--------------------------
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others. These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.
This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.
The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:
- the userspace APIs are (somewhat) normalised
- it's easier to test e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, hence improving their
chances of getting into the kernel
This patch:
Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.
Signed-off-by: Paul Menage <menage@google.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19 14:39:30 +08:00
|
|
|
#endif /* _LINUX_CGROUP_H */
|