RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]

[Sergey Chernyshev]

On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf <sgehwolf at 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