(2012/10/31 13:22), Tejun Heo wrote: > Because ->pre_destroy() could fail and can't be called under > cgroup_mutex, cgroup destruction did something very ugly. > > 1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > > 2. Release cgroup_mutex and call ->pre_destroy(). > > 3. Re-grab cgroup_mutex and verify it can still be destroyed; fail > otherwise. > > 4. Continue destroying. > > In addition to being ugly, it has been always broken in various ways. > For example, memcg ->pre_destroy() expects the cgroup to be inactive > after it's done but tasks can be attached and detached between #2 and > #3 and the conditions that memcg verified in ->pre_destroy() might no > longer hold by the time control reaches #3. > > Now that ->pre_destroy() is no longer allowed to fail. We can switch > to the following. > > 1. Grab cgroup_mutex and fail if it can't be destroyed; fail > otherwise. > > 2. Deactivate CSS's and mark the cgroup removed thus preventing any > further operations which can invalidate the verification from #1. > > 3. Release cgroup_mutex and call ->pre_destroy(). > > 4. Re-grab cgroup_mutex and continue destroying. > > After this change, controllers can safely assume that ->pre_destroy() > will only be called only once for a given cgroup and, once > ->pre_destroy() is called, the cgroup will stay dormant till it's > destroyed. > > Signed-off-by: Tejun Heo <t...@kernel.org>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> Ok, cgroup_lock_live_group() will work synchronously against attach_task(). I welcome this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
