8287073: NPE from CgroupV2Subsystem.getInstance()

[jerboaa]

Simple low-risk backport avoiding a potential NPE on some cgroups v2 systems. Patch applies clean after path unshuffeling.

Testing:

• Container tests on Linux x86_64. Pass.
• Regression test from 8287663: Add a regression test for JDK-8287073 #323

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8287073: NPE from CgroupV2Subsystem.getInstance() (Bug - P4)

Reviewers

• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/324/head:pull/324
$ git checkout pull/324

Update a local copy of the PR:
$ git checkout pull/324
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/324/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 324

View PR using the GUI difftool:
$ git pr show -t 324

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/324.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back sgehwolf! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (a760d6b9)

[jerboaa]

Marking as clean as only the file path has changed to 11u.

/clean

[openjdk]

@jerboaa This backport pull request is now marked as clean

[openjdk]

@jerboaa This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

8287073: NPE from CgroupV2Subsystem.getInstance()

Reviewed-by: andrew

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 21 new commits pushed to the master branch:

• ab2d427: 8232225: Rework the fix for JDK-8071483
• 710481f: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException
• 893340a: 8040887: [TESTBUG] Remove test/runtime/6925573/SortMethodsTest.java
• a039c8a: 8214046: [macosx] Undecorated Frame does not Iconify when set to
• 587090d: Merge
• 50e903b: 8305312: Enhanced path handling
• ec0818a: 8304468: Better array usages
• bd28f3d: 8300596: Enhance Jar Signature validation
• 34c7b2a: 8298676: Enhanced Look and Feel
• fc1b2b4: 8301119: Support for GB18030-2022
• ... and 11 more: https://git.openjdk.org/jdk8u-dev/compare/8efa32e54e23a0fb99cd7df697bec7e6c6baf8bf...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[bridgekeeper]

@jerboaa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[jerboaa]

Please keep open.

[gnu-andrew]

Backport verified clean and approved for 8u.

A question on the general patch out of interest; do we know that infos.values().iterator().next() will return non-null or is it just a lot less likely? I see that Objects.requireNonNull is still going to throw an NPE if it is null, which will at least catch this earlier than the current code.

[jerboaa]

Backport verified clean and approved for 8u.

Thanks!

A question on the general patch out of interest; do we know that infos.values().iterator().next() will return non-null or is it just a lot less likely?

At the point when we pick a controller we already know that at least one of them is available, but we don't know which. Previously we hard-coded to memory, which isn't true when only a cpu controller is in effect. To answer your question, I'm pretty sure we cannot see any null values using infos.values().iterator().next() (or it's a bug, which we've yet to see).

HTH.

[jerboaa]

/integrate

[openjdk]

Going to push as commit 949d8e7.
Since your change was applied there have been 22 commits pushed to the master branch:

• 86ea3f2: 8308788: [8u] Remove duplicate HaricaCA.java test
• ab2d427: 8232225: Rework the fix for JDK-8071483
• 710481f: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException
• 893340a: 8040887: [TESTBUG] Remove test/runtime/6925573/SortMethodsTest.java
• a039c8a: 8214046: [macosx] Undecorated Frame does not Iconify when set to
• 587090d: Merge
• 50e903b: 8305312: Enhanced path handling
• ec0818a: 8304468: Better array usages
• bd28f3d: 8300596: Enhance Jar Signature validation
• 34c7b2a: 8298676: Enhanced Look and Feel
• ... and 12 more: https://git.openjdk.org/jdk8u-dev/compare/8efa32e54e23a0fb99cd7df697bec7e6c6baf8bf...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jerboaa Pushed as commit 949d8e7.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[gnu-andrew]

A question on the general patch out of interest; do we know that infos.values().iterator().next() will return non-null or is it just a lot less likely?

At the point when we pick a controller we already know that at least one of them is available, but we don't know which. Previously we hard-coded to memory, which isn't true when only a cpu controller is in effect. To answer your question, I'm pretty sure we cannot see any null values using infos.values().iterator().next() (or it's a bug, which we've yet to see).

HTH.

It does, thanks.