diff options
author | Peter Zijlstra <[email protected]> | 2016-03-16 16:22:45 +0100 |
---|---|---|
committer | Ingo Molnar <[email protected]> | 2016-03-21 10:49:23 +0100 |
commit | 2f5177f0fd7e531b26d54633be62d1d4cb94621c (patch) | |
tree | 69a5507c68fbf229226275b9a214fbb850fe5b94 /tools/perf/scripts/python/stackcollapse.py | |
parent | 42e405f7b1d252c90a2468dd2140f47b8142b7a0 (diff) |
sched/cgroup: Fix/cleanup cgroup teardown/init
The CPU controller hasn't kept up with the various changes in the whole
cgroup initialization / destruction sequence, and commit:
2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups")
caused it to explode.
The reason for this is that zombies do not inhibit css_offline() from
being called, but do stall css_released(). Now we tear down the cfs_rq
structures on css_offline() but zombies can run after that, leading to
use-after-free issues.
The solution is to move the tear-down to css_released(), which
guarantees nobody (including no zombies) is still using our cgroup.
Furthermore, a few simple cleanups are possible too. There doesn't
appear to be any point to us using css_online() (anymore?) so fold that
in css_alloc().
And since cgroup code guarantees an RCU grace period between
css_released() and css_free() we can forgo using call_rcu() and free the
stuff immediately.
Suggested-by: Tejun Heo <[email protected]>
Reported-by: Kazuki Yamaguchi <[email protected]>
Reported-by: Niklas Cassel <[email protected]>
Tested-by: Niklas Cassel <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions