RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
Severin Gehwolf
sgehwolf at openjdk.org
Mon Dec 2 10:49:38 UTC 2024
On Sun, 1 Dec 2024 12:48:40 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:
> 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:
I assume that's the adjustment logic (pre-patch) that happens provided the setting to `nullptr` issue is addressed in cg v1?
> ```
> /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.
And after the patch this would become this, right?
/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
/sys/fs/cgroup/cpu,cpuacct/
If so, the change of logic isn't that different (except for where the existence checks are happening). This path adjustment only happens at boot, so the next look-up would use `/sys/fs/cgroup/cpu,cpuacct/`. So it's a trade-off, special case this use-case for added complexity or not.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1865630320
More information about the core-libs-dev
mailing list