Hello, Michal.

On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:

On Thu 18-10-12 15:41:48, Tejun Heo wrote:

quoted

Hello, Michal.

On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:

quoted

Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
that css_tryget fails so no new charges for the memcg can happen.
The callbacks are also called from within cgroup_lock to guarantee that
no new tasks show up. We could theoretically call them outside of the
lock but then we have to move after CGRP_REMOVED flag is set.

Signed-off-by: Michal Hocko <redacted>

So, the plan is to do something like the following once memcg is
ready.

  http://thread.gmane.org/gmane.linux.kernel.containers/22559/focus=75251

Note that the patch is broken in a couple places but it does show the
general direction.  I'd prefer if patch #3 simply makes pre_destroy()
return 0 and drop __DEPRECATED_clear_css_refs from mem_cgroup_subsys.

We can still fail inn #3 without this patch becasuse there are is no
guarantee that a new task is attached to the group. And I wanted to keep
memcg and generic cgroup parts separated.

Yes, but all other controllers are broken that way too and the worst
thing which will hapen is triggering WARN_ON_ONCE().  Let's note the
failure in the commit and remove DEPREDATED_clear_css_refs in the
previous patch.  Then, I can pull from you, clean up pre_destroy mess
and then you can pull back for further cleanups.

Thanks.

-- 
tejun