diff options
author | Li Zefan <lizf@cn.fujitsu.com> | 2012-01-20 11:58:43 +0800 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2012-01-20 09:30:08 -0800 |
commit | 245282557c49754af3dbcc732316e814340d6bce (patch) | |
tree | e790dad8b26f273a3509d0a86fb4eec9589e54e7 /kernel/cgroup.c | |
parent | a63b9072ea4e32c1fde8b783ccf6e4288414660b (diff) | |
download | linux-245282557c49754af3dbcc732316e814340d6bce.tar.bz2 |
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.c | 32 |
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. |