summaryrefslogtreecommitdiff
path: root/libpod/pod.go
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2019-07-10 15:09:33 -0400
committerMatthew Heon <matthew.heon@pm.me>2019-07-31 17:28:42 -0400
commitebacfbd091f709d7ca0b811a9fe1fee57c6f0ad3 (patch)
treed25bdc09d9972971ab89bfde8848eb24a271c0e9 /libpod/pod.go
parenta622f8d345b1853401de2e533e9fbf14ef169fa2 (diff)
downloadpodman-ebacfbd091f709d7ca0b811a9fe1fee57c6f0ad3.tar.gz
podman-ebacfbd091f709d7ca0b811a9fe1fee57c6f0ad3.tar.bz2
podman-ebacfbd091f709d7ca0b811a9fe1fee57c6f0ad3.zip
podman: fix memleak caused by renaming and not deleting
the exit file If the container exit code needs to be retained, it cannot be retained in tmpfs, because libpod runs in a memcg itself so it can't leave traces with a daemon-less design. This wasn't a memleak detectable by kmemleak for example. The kernel never lost track of the memory and there was no erroneous refcounting either. The reference count dependencies however are not easy to track because when a refcount is increased, there's no way to tell who's still holding the reference. In this case it was a single page of tmpfs pagecache holding a refcount that kept pinned a whole hierarchy of dying memcg, slab kmem, cgropups, unrechable kernfs nodes and the respective dentries and inodes. Such a problem wouldn't happen if the exit file was stored in a regular filesystem because the pagecache could be reclaimed in such case under memory pressure. The tmpfs page can be swapped out, but that's not enough to release the memcg with CONFIG_MEMCG_SWAP_ENABLED=y. No amount of more aggressive kernel slab shrinking could have solved this. Not even assigning slab kmem of dying cgroups to alive cgroup would fully solve this. The only way to free the memory of a dying cgroup when a struct page still references it, would be to loop over all "struct page" in the kernel to find which one is associated with the dying cgroup which is a O(N) operation (where N is the number of pages and can reach billions). Linking all the tmpfs pages to the memcg would cost less during memcg offlining, but it would waste lots of memory and CPU globally. So this can't be optimized in the kernel. A cronjob running this command can act as workaround and will allow all slab cache to be released, not just the single tmpfs pages. rm -f /run/libpod/exits/* This patch solved the memleak with a reproducer, booting with cgroup.memory=nokmem and with selinux disabled. The reason memcg kmem and selinux were disabled for testing of this fix, is because kmem greatly decreases the kernel effectiveness in reusing partial slab objects. cgroup.memory=nokmem is strongly recommended at least for workstation usage. selinux needs to be further analyzed because it causes further slab allocations. The upstream podman commit used for testing is 1fe2965e4f672674f7b66648e9973a0ed5434bb4 (v1.4.4). The upstream kernel commit used for testing is f16fea666898dbdd7812ce94068c76da3e3fcf1e (v5.2-rc6). Reported-by: Michele Baldessari <michele@redhat.com> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> <Applied with small tweaks to comments> Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'libpod/pod.go')
0 files changed, 0 insertions, 0 deletions