On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
> In the cloudflare case we'd end up with a subsystem path of > `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`. > Since the cgroup_path != _root we trigger path adjustment increasing the > chance to detect any lower limit in any of the paths down to the mount point. > By doing so **and** there is a lower limit in the hierarchy we know the path > exists as well and that is being used from then on. In the Cloudflare case (cg v1 before patch), the path `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c` will be adjusted as follows: /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/ /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/ /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/ /sys/fs/cgroup/cpu,cpuacct/system.slice/ /sys/fs/cgroup/cpu,cpuacct/ In cg v1 systems, all the above paths except for the very last, are invalid. So, no chance for detecting any lower limits. When a process moved to a subgroup, the trailing part of cgroup_path will constitute the subgroup path. > So if `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden` existed > and has a limit it would be used. I thought this is the reason why cg v2 > didn't need the same fix when `--cgroupns=host` is used. The correct reasoning is the following: cg v2 didn't need the same fix, because in cg v2 the entire hierarchy is mapped inside the container in --cgroupns=host mode, the entire path is accessible, including the subgroup. In cg v1 only the process's cgroup is mapped, and the mapping includes subgroups, if any. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1864882109
