On 10/26/2012 03:37 PM, Michal Hocko wrote: > Now that mem_cgroup_pre_destroy callback doesn't fail (other than a race > with a task attach resp. child group appears) 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. > We cannot, however, move cgroup_call_pre_destroy right after because we > cannot call mem_cgroup_pre_destroy with the cgroup_lock held (see > 3fa59dfb cgroup: fix potential deadlock in pre_destroy) so we have to > move it after the lock is released. > If we don't have the cgroup lock held, how safe is the following statement in mem_cgroup_reparent_charges(): if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children)) return -EBUSY; ? IIUC, although this is not generally safe, but it would be safe here because at this point we are expected to had already set the removed bit in the css. If this is the case, however, this condition is impossible and becomes useless - in which case you may want to remove it from Patch1. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>