An absent `memory.max` was documented as proof that nothing above us caps us:
"`systemMemoryCgroupCurrentMB` ... Present means the chain was read and the
missing ceiling really is unlimited — over the ancestors too". The code cannot
establish that. `CgroupCurrentMB` only proves OUR cgroup resolved, and inside a
cgroup namespace — the container/Flatpak case the mount-root fallback exists
for — the walked chain is one level and every ancestor is structurally
unreadable. A `memory.max` on a Kubernetes pod cgroup or on the slice hosting
the container is enforced on us and invisible, so the doc cleared check 2 on
exactly the sandboxes the ancestor walk was added to cover.
`memory.current` exists on non-root cgroups only — the invariant this module
already relies on to reject the host root — so a readable one at the mount root
means the mount root is itself a cgroup, i.e. a namespace root. Report that as
`systemMemoryCgroupChainReachesRoot`, and rewrite the doc's "tell" and check 2
to require it before no-ceiling clears the cgroup.
The flag is excluded from the "nothing was measurable" guard: it always
resolves, and counting it would ship a `Cgroup*` row on every Linux host with
no v2 memory controller at all.
m4air
6fa75179c8