On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <[email protected]> wrote:
>> Please review this change to the cgroup v1 subsystem which makes it more
>> resilient on some of the stranger systems. Unfortunately, I wasn't able to
>> re-create a similar system as the reporter. The idea of using the longest
>> substring match for the cgroupv1 file paths was based on the fact that on
>> systemd systems processes run in separate scopes and the maven forked test
>> runner might exhibit this property. For that it makes sense to use the
>> common ancestor path. Nothing changes in the common cases where the
>> `cgroup_path` matches `_root` and when the `_root` is `/` (container the
>> former, host system the latter).
>>
>> In addition, the code paths which are susceptible to throw NPE have been
>> hardened to catch those situations. Should it happen in the future it makes
>> more sense (to me) to not have accurate container detection in favor of
>> continuing to keep running.
>>
>> Finally, with the added unit-tests a bug was uncovered on the "substring"
>> match case of cgroup paths in hotspot. `p` returned from `strstr` can never
>> point to `_root` as it's used as the "needle" to find in "haystack"
>> `cgroup_path` (not the other way round).
>>
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Use stringStream to simplify controller path assembly
test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:
> 61: ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
> 62: }
> 63: }
I found it hard to relate the different paths. Could you create a new struct
like this?
struct TestCase {
char* mount_path;
char* root_paths;
char* cgroup_path;
char* expected_cg_paths;
} = {
{ "/sys/fs/cgroup/memory", // mount
"/", // root,
....
-------------
PR: https://git.openjdk.java.net/jdk/pull/8629
