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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>