oomd: Fix silent failure to find bad cgroups when another cgroup dies

Consider a workload slice with several sibling cgroups. Imagine that one
of those cgroups is removed between the moment oomd enumerates the
directory and the moment it reads memory.oom.group. This is actually
relatively plausible under the high memory pressure conditions where
oomd is most needed.

In this case, the failed read prompts us to `return 0`, which exits the
entire enumeration loop in recursively_get_cgroup_context(). As a
result, all remaining sibling cgroups are silently dropped from the
candidate list for that monitoring cycle.

The effect is that oomd can fail to identify and kill the actual
offending cgroup, allowing memory pressure to persist until a subsequent
cycle where the race doesn't occur.

Fix this by instead proceeding to evaluate further sibling cgroups.
This commit is contained in:
Chris Down
2026-02-17 17:32:26 +09:00
committed by Yu Watanabe
parent e757e791b2
commit 4fb8cc53b3
+1 -1
View File
@@ -241,7 +241,7 @@ static int recursively_get_cgroup_context(Hashmap *new_h, const char *path) {
return r;
if (r < 0) {
log_debug_errno(r, "Failed to read memory.oom.group from %s, ignoring: %m", cg_path);
return 0;
continue;
}
if (r > 0)
r = oomd_insert_cgroup_context(NULL, new_h, cg_path);