linux-toradex.git/kernel/cgroup.c, branch v3.0.16

cgroups: fix a css_set not found bug in cgroup_attach_proc

2012-01-06T22:13:53+00:00

commit e0197aae59e55c06db172bfbe1a1cdb8c0e1cab3 upstream.

There is a BUG when migrating a PF_EXITING proc. Since css_set_prefetch()
is not called for the PF_EXITING case, find_existing_css_set() will return
NULL inside cgroup_task_migrate() causing a BUG.

This bug is easy to reproduce. Create a zombie and echo its pid to
cgroup.procs.

$ cat zombie.c
\#include 

int main()
{
  if (fork())
      pause();
  return 0;
}
$

We are hitting this bug pretty regularly on ChromeOS.

This bug is already fixed by Tejun Heo's cgroup patchset which is
targetted for the next merge window:

https://lkml.org/lkml/2011/11/1/356

I've create a smaller patch here which just fixes this bug so that a
fix can be merged into the current release and stable.

Signed-off-by: Mandeep Singh Baines 
Downstream-Bug-Report: http://crosbug.com/23953
Reviewed-by: Li Zefan 
Signed-off-by: Tejun Heo 
Cc: containers@lists.linux-foundation.org
Cc: cgroups@vger.kernel.org
Cc: KAMEZAWA Hiroyuki 
Cc: Frederic Weisbecker 
Cc: Oleg Nesterov 
Cc: Andrew Morton 
Cc: Paul Menage 
Cc: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

cgroup: remove the ns_cgroup

2011-05-27T00:12:34+00:00

The ns_cgroup is an annoying cgroup at the namespace / cgroup frontier and
leads to some problems:

  * cgroup creation is out-of-control
  * cgroup name can conflict when pids are looping
  * it is not possible to have a single process handling a lot of
    namespaces without falling in a exponential creation time
  * we may want to create a namespace without creating a cgroup

  The ns_cgroup was replaced by a compatibility flag 'clone_children',
  where a newly created cgroup will copy the parent cgroup values.
  The userspace has to manually create a cgroup and add a task to
  the 'tasks' file.

This patch removes the ns_cgroup as suggested in the following thread:

https://lists.linux-foundation.org/pipermail/containers/2009-June/018616.html

The 'cgroup_clone' function is removed because it is no longer used.

This is a userspace-visible change.  Commit 45531757b45c ("cgroup: notify
ns_cgroup deprecated") (merged into 2.6.27) caused the kernel to emit a
printk warning users that the feature is planned for removal.  Since that
time we have heard from XXX users who were affected by this.

Signed-off-by: Daniel Lezcano 
Signed-off-by: Serge E. Hallyn 
Cc: Eric W. Biederman 
Cc: Jamal Hadi Salim 
Reviewed-by: Li Zefan 
Acked-by: Paul Menage 
Acked-by: Matt Helsley 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cgroups: use flex_array in attach_proc

2011-05-27T00:12:34+00:00

Convert cgroup_attach_proc to use flex_array.

The cgroup_attach_proc implementation requires a pre-allocated array to
store task pointers to atomically move a thread-group, but asking for a
monolithic array with kmalloc() may be unreliable for very large groups.
Using flex_array provides the same functionality with less risk of
failure.

This is a post-patch for cgroup-procs-write.patch.

Signed-off-by: Ben Blum 
Cc: "Eric W. Biederman" 
Cc: Li Zefan 
Cc: Matt Helsley 
Reviewed-by: Paul Menage 
Cc: Oleg Nesterov 
Cc: David Rientjes 
Cc: Miao Xie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cgroups: make procs file writable

2011-05-27T00:12:34+00:00

Make procs file writable to move all threads by tgid at once.

Add functionality that enables users to move all threads in a threadgroup
at once to a cgroup by writing the tgid to the 'cgroup.procs' file.  This
current implementation makes use of a per-threadgroup rwsem that's taken
for reading in the fork() path to prevent newly forking threads within the
threadgroup from "escaping" while the move is in progress.

Signed-off-by: Ben Blum 
Cc: "Eric W. Biederman" 
Cc: Li Zefan 
Cc: Matt Helsley 
Reviewed-by: Paul Menage 
Cc: Oleg Nesterov 
Cc: David Rientjes 
Cc: Miao Xie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cgroups: add per-thread subsystem callbacks

2011-05-27T00:12:34+00:00

Add cgroup subsystem callbacks for per-thread attachment in atomic contexts

Add can_attach_task(), pre_attach(), and attach_task() as new callbacks
for cgroups's subsystem interface.  Unlike can_attach and attach, these
are for per-thread operations, to be called potentially many times when
attaching an entire threadgroup.

Also, the old "bool threadgroup" interface is removed, as replaced by
this.  All subsystems are modified for the new interface - of note is
cpuset, which requires from/to nodemasks for attach to be globally scoped
(though per-cpuset would work too) to persist from its pre_attach to
attach_task and attach.

This is a pre-patch for cgroup-procs-writable.patch.

Signed-off-by: Ben Blum 
Cc: "Eric W. Biederman" 
Cc: Li Zefan 
Cc: Matt Helsley 
Reviewed-by: Paul Menage 
Cc: Oleg Nesterov 
Cc: David Rientjes 
Cc: Miao Xie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cgroup,rcu: convert call_rcu(__free_css_id_cb) to kfree_rcu()

2011-05-08T05:50:47+00:00

The rcu callback __free_css_id_cb() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(__free_css_id_cb).

Signed-off-by: Lai Jiangshan 
Acked-by: Paul Menage 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

cgroup,rcu: convert call_rcu(free_cgroup_rcu) to kfree_rcu()

2011-05-08T05:50:46+00:00

The rcu callback free_cgroup_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(free_cgroup_rcu).

Signed-off-by: Lai Jiangshan 
Acked-by: Paul Menage 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

cgroup,rcu: convert call_rcu(free_css_set_rcu) to kfree_rcu()

2011-05-08T05:50:45+00:00

The rcu callback free_css_set_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(free_css_set_rcu).

Signed-off-by: Lai Jiangshan 
Acked-by: Paul Menage 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

cgroups: if you list_empty() a head then don't list_del() it

2011-03-23T00:43:58+00:00

list_del() leaves poison in the prev and next pointers.  The next
list_empty() will compare those poisons, and say the list isn't empty.
Any list operations that assume the node is on a list because of such a
check will be fooled into dereferencing poison.  One needs to INIT the
node after the del, and fortunately there's already a wrapper for that -
list_del_init().

Some of the dels are followed by deallocations, so can be ignored, and one
can be merged with an add to make a move.  Apart from that, I erred on the
side of caution in making nodes list_empty()-queriable.

Signed-off-by: Phil Carmody 
Reviewed-by: Paul Menage 
Cc: Li Zefan 
Acked-by: Kirill A. Shutemov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds