summaryrefslogtreecommitdiff
path: root/kernel/cgroup.c
diff options
context:
space:
mode:
authorLi Zefan <lizf@cn.fujitsu.com>2012-01-20 11:58:43 +0800
committerTejun Heo <tj@kernel.org>2012-01-20 09:30:08 -0800
commit245282557c49754af3dbcc732316e814340d6bce (patch)
treee790dad8b26f273a3509d0a86fb4eec9589e54e7 /kernel/cgroup.c
parenta63b9072ea4e32c1fde8b783ccf6e4288414660b (diff)
downloadlwn-245282557c49754af3dbcc732316e814340d6bce.tar.gz
lwn-245282557c49754af3dbcc732316e814340d6bce.zip
cgroup: move struct cgroup_pidlist out from the header file
It's internally used only. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'kernel/cgroup.c')
-rw-r--r--kernel/cgroup.c32
1 files changed, 32 insertions, 0 deletions
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5d3b5325f77..6ca7acad7c55 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3043,6 +3043,38 @@ int cgroup_scan_tasks(struct cgroup_scanner *scan)
*
*/
+/* which pidlist file are we talking about? */
+enum cgroup_filetype {
+ CGROUP_FILE_PROCS,
+ CGROUP_FILE_TASKS,
+};
+
+/*
+ * A pidlist is a list of pids that virtually represents the contents of one
+ * of the cgroup files ("procs" or "tasks"). We keep a list of such pidlists,
+ * a pair (one each for procs, tasks) for each pid namespace that's relevant
+ * to the cgroup.
+ */
+struct cgroup_pidlist {
+ /*
+ * used to find which pidlist is wanted. doesn't change as long as
+ * this particular list stays in the list.
+ */
+ struct { enum cgroup_filetype type; struct pid_namespace *ns; } key;
+ /* array of xids */
+ pid_t *list;
+ /* how many elements the above list has */
+ int length;
+ /* how many files are using the current array */
+ int use_count;
+ /* each of these stored in a list by its cgroup */
+ struct list_head links;
+ /* pointer to the cgroup we belong to, for list removal purposes */
+ struct cgroup *owner;
+ /* protects the other fields */
+ struct rw_semaphore mutex;
+};
+
/*
* The following two functions "fix" the issue where there are more pids
* than kmalloc will give memory for; in such cases, we use vmalloc/vfree.