On Fri, Apr 27, 2012 at 03:04:14PM +0900, KAMEZAWA Hiroyuki wrote: > When ->pre_destroy() is called, it should be guaranteed that > new child cgroup is not created under a cgroup, where pre_destroy() > is running. If not, ->pre_destroy() must check children and > return -EBUSY, which causes warning. > > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> Hmm... I'm getting confused more. Why do we need these cgroup changes at all? cgroup still has cgrp->count check and cgroup_clear_css_refs() after pre_destroy() calls. The order of changes should be, * Make memcg pre_destroy() not fail; however, pre_destroy() should still be ready to be retried. That's the defined interface. * cgroup core updated to drop pre_destroy() retrying and guarantee that pre_destroy() invocation will happen only once. * memcg and other cgroups can update their pre_destroy() if the "won't be retried" part can simplify their implementations. So, there's no reason to be updating cgroup pre_destroy() semantics at this point and these updates actually break cgroup API as it currently stands. The only change necessary is memcg's pre_destroy() not returning zero. Thanks. -- tejun -- 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
