[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121031190237.GA1271@dhcp22.suse.cz>
Date: Wed, 31 Oct 2012 20:02:37 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Tejun Heo <tj@...nel.org>
Cc: lizefan@...wei.com, hannes@...xchg.org, bsingharora@...il.com,
kamezawa.hiroyu@...fujitsu.com,
containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/8] cgroup: kill
cgroup_subsys->__DEPRECATED_clear_css_refs
On Wed 31-10-12 11:16:24, Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECATED_clear_css_refs removed.
>
> * ->pre_destroy() now can only fail if a new task is attached or child
> cgroup is created while ->pre_destroy()s are being called. As the
> condition is checked again after re-acquiring cgroup_mutex
> afterwards, we don't need to take any immediate action on
> ->pre_destroy() failures.
Well, this is racy because the task can exit until we reach the
re-check. As the result there might still be some pages on the memcg
LRUs left.
As I said in the previous version, I do not see any reason why we
shouldn't just return EBUSY here. I would even skip WARN_ON_ONCE because
it doesn't give us any valueable information. One can trigger that
easily as well.
[...]
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 7981850..033bf4b 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
[...]
> @@ -4168,11 +4075,9 @@ again:
> * Call pre_destroy handlers of subsys. Notify subsystems
> * that rmdir() request comes.
> */
> - ret = cgroup_call_pre_destroy(cgrp);
> - if (ret) {
> - clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags);
> - return ret;
> - }
> + for_each_subsys(cgrp->root, ss)
> + if (ss->pre_destroy)
> + WARN_ON_ONCE(ss->pre_destroy(cgrp));
for_each_subsys(cgrp->root, ss)
if (ss->pre_destroy) {
int ret = ss->pre_destroy(cgrp);
clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags);
return ret;
}
>
> mutex_lock(&cgroup_mutex);
> parent = cgrp->parent;
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists