(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
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
