History

memcg: fix hierarchical oom locking

Commit 79dfdaccd1d5 ("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.

Johannes Weiner committed 15 years ago

Commit 23751be1 parent 86383b51 file · +5 −12Browse files

Unified · Split

mm/memcontrol.c+5−12
@@ -1841,29 +1841,23 @@ static int mem_cgroup_hierarchical_reclaim(struct mem_cgroup *root_mem, · 1840 unmodified lines
18411841 */
18421842 static bool mem_cgroup_oom_lock(struct mem_cgroup *mem)
18431843 {
1844− int lock_count = -1;
18451844 struct mem_cgroup *iter, *failed = NULL;
18461845 bool cond = true;
18471846
18481847 for_each_mem_cgroup_tree_cond(iter, mem, cond) {
1849− bool locked = iter->oom_lock;
1850−
1851− iter->oom_lock = true;
1852− if (lock_count == -1)
1853− lock_count = iter->oom_lock;
1854− else if (lock_count != locked) {
1848+ if (iter->oom_lock) {
18551849 /*
18561850 * this subtree of our hierarchy is already locked
18571851 * so we cannot give a lock.
18581852 */
1859− lock_count = 0;
18601853 failed = iter;
18611854 cond = false;
1862− }
1855+ } else
1856+ iter->oom_lock = true;
18631857 }
18641858
18651859 if (!failed)
1866− goto done;
1860+ return true;
18671861
18681862 /*
18691863 * OK, we failed to lock the whole subtree so we have to clean up
@@ -1877,8 +1871,7 @@ static bool mem_cgroup_oom_lock(struct mem_cgroup *mem) · 7 unmodified lines
18771871 }
18781872 iter->oom_lock = false;
18791873 }
1880−done:
1881− return lock_count;
1874+ return false;
18821875 }
18831876
18841877 /*