Re: [PATCH v3 4/6] cgroups: forbid pre_destroy callback to fail

[Glauber Costa]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/