On Fri, 7 Mar 2025 04:34:24 GMT, David Holmes wrote:
>>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
>>> well.
>>
>> Thanks for your review @jerboaa ! I cheched the
>> test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master
>> branch.
>
> @se
On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev
wrote:
>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
>> well.
>
>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
>> well.
>
> Thanks for your review @jerboaa ! I cheched the
> te
On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev
wrote:
> > OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
> > well.
>
> Thanks for your review @jerboaa ! I cheched the
> test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master
> branch.
OK!
On Sun, 2 Mar 2025 19:07:32 GMT, Severin Gehwolf wrote:
> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
> well.
Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp,
it's already updated to 2025 in the master branch.
-
PR Co
On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Fri, 28 Feb 2025 17:08:19 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated comment
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
On Fri, 28 Feb 2025 12:27:13 GMT, Matthias Baesken wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated comment
>
> test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java
> line 69:
>
On Fri, 28 Feb 2025 17:07:59 GMT, Severin Gehwolf wrote:
>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2020, 2024, Red Hat Inc.
>>
>> Guess this must be 2025 now ? Same for other files ...
>
> yes indeed.
indeed, updated the copyright headers.
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Fri, 28 Feb 2025 12:19:53 GMT, Matthias Baesken wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated comment
>
> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
>
>> 1: /*
>> 2: * Copyright (c
On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Tue, 25 Feb 2025 17:11:30 GMT, Severin Gehwolf wrote:
>>> This needs to explain exactly what is happening when. The current comment
>>> isn't even remotely explaining in detail what it does. What does "...
>>> handles the case when a process is moved between cgroups" mean exactly?
>>
>> Eit
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev
wrote:
>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to
>> describe the logic happening.
>>
>> Testing:
And after the patch this would become this, right?
```
/sys/fs/cgroup/cpu,cpuacct/system.slice/g
On Tue, 25 Feb 2025 16:31:05 GMT, Sergey Chernyshev
wrote:
>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42:
>>
>>> 40: * When runs in a container, the method handles the case
>>> 41: * when a process is moved between cgroups.
>>> 42: */
>>
>> This needs to explain exactly what i
On Tue, 25 Feb 2025 14:06:03 GMT, Severin Gehwolf wrote:
> This needs to explain exactly what is happening when. The current comment
> isn't even remotely explaining in detail what it does. What does "... handles
> the case when a process is moved between cgroups" mean exactly?
Either it shall
On Mon, 24 Feb 2025 21:20:49 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev
wrote:
>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to
>> describe the logic happening.
>>
>> Testing:
And after the patch this would become this, right?
```
/sys/fs/cgroup/cpu,cpuacct/system.slice/g
On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote:
> The above case, doesn't seem to be reflected by any gtest test case (or
> others), please add those.
The subgroup path reduction is covered by
`TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in
gtests as i
On Fri, 21 Feb 2025 20:05:07 GMT, Sergey Chernyshev
wrote:
>> Good catch, but as long as cgp#nameCount may change in the loop, this exact
>> patch i cannot take.
>
> How about this?
>
> int currentNameCount = cgp.getNameCount();
> cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount)
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote:
> `CgroupV1Controller::set_subsystem_path` needs high level comment update to
> describe the logic happening.
>
Done, added
-
PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679664923
On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 73:
>>
>>> 71: break;
>>> 72: }
>>> 73: cgp
On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Mon, 17 Feb 2025 11:09:12 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsyst
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Mon, 17 Feb 2025 15:48:51 GMT, Matthias Baesken wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsys
On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Tue, 3 Dec 2024 10:06:39 GMT, Sergey Chernyshev
wrote:
>> Sergey Chernyshev has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - update cgroup v1 in metrics
>> - Apply suggestions from code review
>>
>>Co-authored-by: Severin
On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf wrote:
>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to
>> '../../test', detected limits won't be accurate```
>> This way it will have all the
On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf wrote:
>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to
>> '../../test', detected limits won't be accurate```
>> This way it will have all the
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Wed, 11 Dec 2024 15:19:06 GMT, Sergey Chernyshev
wrote:
>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322:
>>
>>> 320: } else {
>>> 321: log_warning(os, container)("Cgroup cpu/memory controller path
>>> includes '../', detected limits won't be accurate");
>>> 322: }
On Fri, 6 Dec 2024 09:51:52 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 13 commits:
>>
>> - diverged after integration of JDK-8344177
>>
>># Conflicts:
>># src/java
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Thu, 5 Dec 2024 20:05:56 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Sat, 30 Nov 2024 00:30:02 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Mon, 2 Dec 2024 10:47:01 GMT, Severin Gehwolf wrote:
> 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/
> ```
It depends on whether it was a subgroup in th
On Sun, 1 Dec 2024 12:48:40 GMT, Sergey Chernyshev
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)
On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf 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
On Wed, 27 Nov 2024 11:07:18 GMT, Severin Gehwolf wrote:
> Right. I'm still not convinced this extra reduction buys us much. The adjust
> controller logic will handle it if kept as is in the Metrics version.
The adjust controller logic won't handle it, because it reduces the path from
child to
On Wed, 27 Nov 2024 09:11:22 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Fri, 29 Nov 2024 14:47:13 GMT, Sergey Chernyshev
wrote:
> > Right. I'm still not convinced this extra reduction buys us much. The
> > adjust controller logic will handle it if kept as is in the Metrics version.
>
> The adjust controller logic won't handle it, because it reduces the path fro
On Wed, 27 Nov 2024 10:56:57 GMT, Sergey Chernyshev
wrote:
>>> Version specific code can be had in `set_subsystem_path()` of the
>>> corresponding impl (like an earlier version of your patch). `lowest_limit`
>>> and `limit_cg_path` fixes are version agnostic and can and should be fixed
>>> in
On Wed, 27 Nov 2024 10:18:24 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust path suffix in cgroup (v1) version specific code, when root !=
>> cgroup
>
> src/hotspot/os/linux/cgrou
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Wed, 27 Nov 2024 09:11:22 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Wed, 27 Nov 2024 09:08:30 GMT, Sergey Chernyshev
wrote:
> Done. Please see the updated PR.
The metrics part still needs the update - in the cgroup version specific
`setPath()`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860451322
On Mon, 25 Nov 2024 09:44:33 GMT, Severin Gehwolf wrote:
> ```
> "echo '+memory' > /sys/fs/cgroup/memory/cgroup.subtree_control ; "
> ```
>
> ... relies on the user in the container image to be `root`. So depending on
> which base image is being used - by means of
> `-Djdk.test.docker.image.na
On Mon, 25 Nov 2024 09:40:03 GMT, Severin Gehwolf wrote:
> Version specific code can be had in `set_subsystem_path()` of the
> corresponding impl (like an earlier version of your patch). `lowest_limit`
> and `limit_cg_path` fixes are version agnostic and can and should be fixed in
> `CgroupUti
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Fri, 22 Nov 2024 15:08:18 GMT, Sergey Chernyshev
wrote:
> > One thing to note is that the new test requires root privileges (AFAIK). We
> > should skip the test if we are being run as root.
>
> The test works just like other docker tests, root privileges are not
> required. In systems that
On Sat, 23 Nov 2024 10:28:42 GMT, Sergey Chernyshev
wrote:
>>> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
>>> when path adjustment is deemed needed. So I'm not clear why it's needed for
>>> cg v2
>>
>> It looks like there's no way to see at this point, if we ar
On Sat, 23 Nov 2024 00:06:26 GMT, Sergey Chernyshev
wrote:
> It looks like there's no way to see at this point, if we are in cgroup v1 or
> v2 - if I am not mistaken.
On the other hand, a type parameter can be added to
`CgroupUtil::adjust_controller()`. Would you recommend doing so?
On Fri, 22 Nov 2024 16:48:04 GMT, Severin Gehwolf wrote:
> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
> when path adjustment is deemed needed. So I'm not clear why it's needed for
> cg v2
It looks like there's no way to see at this point, if we are in cgroup v1
On Fri, 22 Nov 2024 13:00:14 GMT, Sergey Chernyshev
wrote:
>>> Here, `limit` at line 64 is not stored as a possible lowest limit, so if
>>> the inner group has lower limit than the outer group, it won't be detected
>>> (cg v2 is affected too).
>>
>> Good spot! How about this to fix it?
>>
>>
On Fri, 22 Nov 2024 10:57:31 GMT, Severin Gehwolf wrote:
> One thing to note is that the new test requires root privileges (AFAIK). We
> should skip the test if we are being run as root.
The test works just like other docker tests, root privileges are not required.
In systems that can't run do
On Fri, 22 Nov 2024 10:54:34 GMT, Severin Gehwolf wrote:
> Good spot! How about this to fix it?
>
> ```
> jlong limit = mem->read_memory_limit_in_bytes(phys_mem);
> jlong lowest_limit = limit < 0 ? phys_mem: limit;
> ```
Make sense to me.
> I'm worried about the added complexity. 1.) Is this
On Fri, 22 Nov 2024 09:54:39 GMT, Sergey Chernyshev
wrote:
> Here, `limit` at line 64 is not stored as a possible lowest limit, so if the
> inner group has lower limit than the outer group, it won't be detected (cg v2
> is affected too).
Good spot! How about this to fix it?
jlong limit = me
On Fri, 22 Nov 2024 09:57:44 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Tue, 12 Nov 2024 23:29:47 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 46:
>>
>>> 44: }
>>> 45:
>>> 46: public void setPath(String cgroupPath) {
>>
>> This should behave the same as Hotspot and
On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>>
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Tue, 12 Nov 2024 14:59:41 GMT, Sergey Chernyshev
wrote:
> > The JBS issue doesn't mention `NullPointerException`. It would be good to
> > list the observed NPE issue.
>
> Example for NPE:
>
> ```
> public class Test {
> public static void main(String[] args) {
> java.lang.manag
On Tue, 12 Nov 2024 19:09:54 GMT, Sergey Chernyshev
wrote:
> > Edit: Yet, cg v2 will get into trouble since there, for example on rootless
> > podman on cg v2 you'd end up with this instead:
> > ```
> > [0.008s][trace][os,container] OSContainer::init: Initializing Container
> > Support
> > [0.
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf wrote:
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
Example for NPE:
public class Test {
public static void main(String[] args) {
java.lang.management.ManagementFactory.
On Mon, 11 Nov 2024 18:28:11 GMT, Sergey Chernyshev
wrote:
> > So on cg v1 you start out and end with a `subsystem_path() == null` and on
> > cg v2 you start out and end with a `subsystem_path() ==
> > /../../../../../../test`. In both cases the memory limit of 400m won't be
> > detected.
>
On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf wrote:
> So on cg v1 you start out and end with a `subsystem_path() == null` and on cg
> v2 you start out and end with a `subsystem_path() ==
> /../../../../../../test`. In both cases the memory limit of 400m won't be
> detected.
Only when doc
On Mon, 11 Nov 2024 15:16:15 GMT, Severin Gehwolf wrote:
> On cg v2, on the other hand, `set_subsystem_path()` will never set the path
> to a `null` value.
Exactly. That's why JDK-8322420 is not in effect and also
[JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) does not fix it on
J
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Mon, 11 Nov 2024 10:20:02 GMT, Severin Gehwolf wrote:
> > In the above script, a containerized process (/bin/sh) is moved to cgroup
> > /test before /jdk/bin/java gets executed. Java inherits cgroup /test from
> > its parent process, its _root will be /docker/, cgroup_path
> > will be /test
On Mon, 11 Nov 2024 10:06:11 GMT, Severin Gehwolf wrote:
> > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
>
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
I also wonder, then, if the issue is NPE if
[JD
On Thu, 7 Nov 2024 13:28:29 GMT, Sergey Chernyshev
wrote:
> Create a new cgroup for memory
>
> ```
> sudo mkdir -p /sys/fs/cgroup/memory/test
> ```
>
> Run the following script
>
> ```
> docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m
> ubuntu:latest \
> sh -c "sleep 10
On Fri, 8 Nov 2024 16:11:37 GMT, Sergey Chernyshev
wrote:
> I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
The JBS issue doesn't mention `NullPointerException`. It would be good to list
the observed NPE issue.
-
PR Comment: https://git.openjdk.org/jdk
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
On Fri, 1 Nov 2024 13:13:07 GMT, Sergey Chernyshev
wrote:
> As they're in fact mounting read-write, the logic picked up `rw` mount option
> and falsely detected "host mode". Also the `--privileged` creates `rw`
> mounts, so the entire approach needs correction.
Yes. See https://bugs.openjdk.o
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
Cgroup V1 subsustem fails to initialize mounted controllers properly in certain
cases, that may lead to controllers left undetected/inactive. We observed the
behavior in CloudFoundry deployments, it affects also host systems.
The relevant /proc/self/mountinfo line is
2207 2196 0:43
/system.sl
98 matches
Mail list logo
