RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v2]

[Severin Gehwolf]

On Tue, 27 Aug 2024 14:04:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>>  - Remove some duplication
>>  - Fix style
>>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>>  - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected
>
> src/hotspot/os/linux/cgroupUtil_linux.cpp line 58:
> 
>> 56:   log_trace(os, container)("Adjusting controller path for memory: %s", mem->subsystem_path());
>> 57:   assert(mem->cgroup_path() != nullptr, "invariant");
>> 58:   char* orig = os::strdup(mem->cgroup_path());
> 
> Why do we strdup orig?
> 
> Ah, I see, because we need to modify the controller object because the only way to get the new limit value is to ask it, and so it needs to be set to the new path, but that new path may turn out to be wrong, so we need to restore the original path. And we cannot just create a new controller on the fly to check the limit because all we have here is the abstract `CgroupMemoryController` interface, and we don't know if we deal with V1 or V2 here. Sigh...

Yes. We could add deep-copying function to create a new one, but it seems unnecessary copying of other parts just to (potentially) do a look-up on a path we don't know yet is the one we'll pick.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20646#discussion_r1733353472