Cleaning up vmpressure from mem_cgroup_css_offline() doesn't look safe. It looks like mem_cgroup_css_offline() might race with reclaim which will queue vmpressure work after the flush.
Put vmpressure_cleanup() in mem_cgroup_css_free() where we have exclusive access to memcg. It was originally there, see https://jira.sw.ru/browse/PSBM-93884 but moved in a process of rebase. https://jira.sw.ru/browse/PSBM-122653 Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/memcontrol.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e36ad592b3c7..803273a4d9cb 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6822,8 +6822,6 @@ static void mem_cgroup_css_offline(struct cgroup *cont) mem_cgroup_free_all(memcg); mem_cgroup_reparent_charges(memcg); - vmpressure_cleanup(&memcg->vmpressure); - /* * A cgroup can be destroyed while somebody is waiting for its * oom context, in which case the context will never be unlocked @@ -6878,7 +6876,7 @@ static void mem_cgroup_css_free(struct cgroup *cont) mem_cgroup_reparent_charges(memcg); cancel_work_sync(&memcg->high_work); - + vmpressure_cleanup(&memcg->vmpressure); memcg_destroy_kmem(memcg); memcg_free_shrinker_maps(memcg); __mem_cgroup_free(memcg); -- 2.26.2 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
