(2012/07/21 4:56), Tejun Heo wrote:

On Sat, Jul 21, 2012 at 12:48:34AM +0530, Aneesh Kumar K.V wrote:

quoted

Does cgroup_rmdir do a cgroup_task_count check ? I do see that it check
cgroup->childern and cgroup->count. But cgroup->count is not same as
task_count right ?

May be we need to push the task_count check also to rmdir so that
pre_destory doesn't need to check this

task_count implies cgroup refcnt which cgroup core does check.  No
need to worry about that, ->children or whatever from memcg.  As soon
as the deprecated behavior is gone, everything will be okay;
otherwise, it's a bug in cgroup core.

I'm sorry I misunderstand. The problem is following.

         CPU A                       CPU B
     mutex_unlock()
                                 mutex_lock()
     ->pre_destroy()             attach task
       commit res->usage=0       mutex_unlock()
                                 increase res->usage
                                 detach task
     mutex_lock()
     check css's refcount=0
      ....continue destroy.

Now, I thinks memcg's check is not enough but putting the -EBUSY there
not to forget this race.


I think a patch to stop task-attach and create child cgroup if  CGRP_WAIT_ON_RMDIR
is set is required. And that's enough..
Thanks,
-Kame