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

move d_rcu from overlapping d_child to overlapping d_alias

2015-04-29T08:31:54+00:00

commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream.

move d_rcu from overlapping d_child to overlapping d_alias

Signed-off-by: Al Viro 
Cc: Ben Hutchings 
[hujianyang: Backported to 3.14 refer to the work of Ben Hutchings in 3.2:
 - Apply name changes in all the different places we use d_alias and d_child
 - Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
Signed-off-by: hujianyang 
Signed-off-by: Greg Kroah-Hartman

cgroup: fix unbalanced locking

2014-10-05T21:52:17+00:00

commit eb4aec84d6bdf98d00cedb41c18000f7a31e648a upstream.

cgroup_pidlist_start() holds cgrp->pidlist_mutex and then calls
pidlist_array_load(), and cgroup_pidlist_stop() releases the mutex.

It is wrong that we release the mutex in the failure path in
pidlist_array_load(), because cgroup_pidlist_stop() will be called
no matter if cgroup_pidlist_start() returns errno or not.

Fixes: 4bac00d16a8760eae7205e41d2c246477d42a210
Signed-off-by: Zefan Li 
Signed-off-by: Tejun Heo 
Acked-by: Cong Wang 
Signed-off-by: Greg Kroah-Hartman

cgroup: fix a failure path in create_css()

2014-03-18T21:15:36+00:00

If online_css() fails, we should remove cgroup files belonging
to css->ss.

Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo

cgroup: update cgroup_enable_task_cg_lists() to grab siglock

2014-02-18T23:23:18+00:00

Currently, there's nothing preventing cgroup_enable_task_cg_lists()
from missing set PF_EXITING and race against cgroup_exit().  Depending
on the timing, cgroup_exit() may finish with the task still linked on
css_set leading to list corruption.  Fix it by grabbing siglock in
cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be
visible.

This whole on-demand cg_list optimization is extremely fragile and has
ample possibility to lead to bugs which can cause things like
once-a-year oops during boot.  I'm wondering whether the better
approach would be just adding "cgroup_disable=all" handling which
disables the whole cgroup rather than tempting fate with this
on-demand craziness.

Signed-off-by: Tejun Heo 
Acked-by: Li Zefan 
Cc: stable@vger.kernel.org

Revert "cgroup: use an ordered workqueue for cgroup destruction"

2014-02-13T00:08:28+00:00

This reverts commit ab3f5faa6255a0eb4f832675507d9e295ca7e9ba.
Explanation from Hugh:

  It's because more thorough testing, by others here, found that it
  wasn't always solving the problem: so I asked Tejun privately to
  hold off from sending it in, until we'd worked out why not.

  Most of our testing being on a v3,11-based kernel, it was perfectly
  possible that the problem was merely our own e.g. missing Tejun's
  8a2b75384444 ("workqueue: fix ordered workqueues in NUMA setups").

  But that turned out not to be enough to fix it either. Then Filipe
  pointed out how percpu_ref_kill_and_confirm() uses call_rcu_sched()
  before we ever get to put the offline on to the workqueue: by the
  time we get to the workqueue, the ordering has already been lost.

  So, thanks for the Acks, but I'm afraid that this ordered workqueue
  solution is just not good enough: we should simply forget that patch
  and provide a different answer."

Signed-off-by: Tejun Heo 
Cc: Hugh Dickins

cgroup: protect modifications to cgroup_idr with cgroup_mutex

2014-02-11T15:38:30+00:00

Setup cgroupfs like this:
  # mount -t cgroup -o cpuacct xxx /cgroup
  # mkdir /cgroup/sub1
  # mkdir /cgroup/sub2

Then run these two commands:
  # for ((; ;)) { mkdir /cgroup/sub1/tmp && rmdir /mnt/sub1/tmp; } &
  # for ((; ;)) { mkdir /cgroup/sub2/tmp && rmdir /mnt/sub2/tmp; } &

After seconds you may see this warning:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 25243 at lib/idr.c:527 sub_remove+0x87/0x1b0()
idr_remove called for id=6 which is not allocated.
...
Call Trace:
 [] dump_stack+0x7a/0x96
 [] warn_slowpath_common+0x8c/0xc0
 [] warn_slowpath_fmt+0x46/0x50
 [] sub_remove+0x87/0x1b0
 [] ? css_killed_work_fn+0x32/0x1b0
 [] idr_remove+0x25/0xd0
 [] cgroup_destroy_css_killed+0x5b/0xc0
 [] css_killed_work_fn+0x130/0x1b0
 [] process_one_work+0x26c/0x550
 [] worker_thread+0x12e/0x3b0
 [] kthread+0xe6/0xf0
 [] ret_from_fork+0x7c/0xb0
---[ end trace 2d1577ec10cf80d0 ]---

It's because allocating/removing cgroup ID is not properly synchronized.

The bug was introduced when we converted cgroup_ida to cgroup_idr.
While synchronization is already done inside ida_simple_{get,remove}(),
users are responsible for concurrent calls to idr_{alloc,remove}().

tj: Refreshed on top of b58c89986a77 ("cgroup: fix error return from
cgroup_create()").

Fixes: 4e96ee8e981b ("cgroup: convert cgroup_ida to cgroup_idr")
Cc:  #3.12+
Reported-by: Michal Hocko 
Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo

cgroup: fix locking in cgroup_cfts_commit()

2014-02-08T15:26:34+00:00

cgroup_cfts_commit() walks the cgroup hierarchy that the target
subsystem is attached to and tries to apply the file changes.  Due to
the convolution with inode locking, it can't keep cgroup_mutex locked
while iterating.  It currently holds only RCU read lock around the
actual iteration and then pins the found cgroup using dget().

Unfortunately, this is incorrect.  Although the iteration does check
cgroup_is_dead() before invoking dget(), there's nothing which
prevents the dentry from going away inbetween.  Note that this is
different from the usual css iterations where css_tryget() is used to
pin the css - css_tryget() tests whether the css can be pinned and
fails if not.

The problem can be solved by simply holding cgroup_mutex instead of
RCU read lock around the iteration, which actually reduces LOC.

Signed-off-by: Tejun Heo 
Acked-by: Li Zefan 
Cc: stable@vger.kernel.org

cgroup: fix error return from cgroup_create()

2014-02-08T15:26:33+00:00

cgroup_create() was returning 0 after allocation failures.  Fix it.

Signed-off-by: Tejun Heo 
Acked-by: Li Zefan 
Cc: stable@vger.kernel.org

cgroup: fix error return value in cgroup_mount()

2014-02-08T15:26:33+00:00

When cgroup_mount() fails to allocate an id for the root, it didn't
set ret before jumping to unlock_drop ending up returning 0 after a
failure.  Fix it.

Signed-off-by: Tejun Heo 
Acked-by: Li Zefan 
Cc: stable@vger.kernel.org

cgroup: use an ordered workqueue for cgroup destruction

2014-02-07T15:21:12+00:00

Sometimes the cleanup after memcg hierarchy testing gets stuck in
mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0.

There may turn out to be several causes, but a major cause is this: the
workitem to offline parent can get run before workitem to offline child;
parent's mem_cgroup_reparent_charges() circles around waiting for the
child's pages to be reparented to its lrus, but it's holding cgroup_mutex
which prevents the child from reaching its mem_cgroup_reparent_charges().

Just use an ordered workqueue for cgroup_destroy_wq.

tj: Committing as the temporary fix until the reverse dependency can
    be removed from memcg.  Comment updated accordingly.

Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction")
Suggested-by: Filipe Brandenburger 
Signed-off-by: Hugh Dickins 
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Tejun Heo