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