The patch titled memcg: fix hierarchical oom locking has been added to the -mm tree. Its filename is memcg-make-oom_lock-0-and-1-based-rather-than-coutner.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: memcg: fix hierarchical oom locking From: Johannes Weiner <jweiner@xxxxxxxxxx> Commit 79dfdac ("memcg: make oom_lock 0 and 1 based rather than counter") tried to oom lock the hierarchy and roll back upon encountering an already locked memcg. The code is confused when it comes to detecting a locked memcg, though, so it would fail and rollback after locking one memcg and encountering an unlocked second one. The result is that oom-locking hierarchies fails unconditionally and that every oom killer invocation simply goes to sleep on the oom waitqueue forever. The tasks practically hang forever without anyone intervening, possibly holding locks that trip up unrelated tasks, too. Signed-off-by: Johannes Weiner <jweiner@xxxxxxxxxx> Acked-by: Michal Hocko <mhocko@xxxxxxx> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/memcontrol.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff -puN mm/memcontrol.c~memcg-make-oom_lock-0-and-1-based-rather-than-coutner mm/memcontrol.c --- a/mm/memcontrol.c~memcg-make-oom_lock-0-and-1-based-rather-than-coutner +++ a/mm/memcontrol.c @@ -1842,29 +1842,23 @@ static int mem_cgroup_hierarchical_recla */ static bool mem_cgroup_oom_lock(struct mem_cgroup *mem) { - int lock_count = -1; struct mem_cgroup *iter, *failed = NULL; bool cond = true; for_each_mem_cgroup_tree_cond(iter, mem, cond) { - bool locked = iter->oom_lock; - - iter->oom_lock = true; - if (lock_count == -1) - lock_count = iter->oom_lock; - else if (lock_count != locked) { + if (iter->oom_lock) { /* * this subtree of our hierarchy is already locked * so we cannot give a lock. */ - lock_count = 0; failed = iter; cond = false; - } + } else + iter->oom_lock = true; } if (!failed) - goto done; + return true; /* * OK, we failed to lock the whole subtree so we have to clean up @@ -1878,8 +1872,7 @@ static bool mem_cgroup_oom_lock(struct m } iter->oom_lock = false; } -done: - return lock_count; + return false; } /* _ Patches currently in -mm which might be from jweiner@xxxxxxxxxx are memcg-pin-execution-to-current-cpu-while-draining-stock.patch memcg-make-oom_lock-0-and-1-based-rather-than-coutner.patch linux-next.patch mm-vmscan-fix-force-scanning-small-targets-without-swap.patch mm-vmscan-fix-force-scanning-small-targets-without-swap-fix.patch mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch mm-vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch mm-vmscan-remove-dead-code-related-to-lumpy-reclaim-waiting-on-pages-under-writeback.patch xfs-warn-if-direct-reclaim-tries-to-writeback-pages.patch ext4-warn-if-direct-reclaim-tries-to-writeback-pages.patch mm-vmscan-do-not-writeback-filesystem-pages-in-kswapd-except-in-high-priority.patch mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback.patch mm-vmscan-immediately-reclaim-end-of-lru-dirty-pages-when-writeback-completes.patch memcg-remove-unneeded-preempt_disable.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html