Re: + hugetlb-cgroup-simplify-pre_destroy-callback.patch added to -mm tree

[Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]

(2012/07/21 4:56), Tejun Heo wrote:
> On Sat, Jul 21, 2012 at 12:48:34AM +0530, Aneesh Kumar K.V wrote:
>> 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