RFR: 8253435: Cgroup: 'stomping of _mount_path' crash if manually mounted cpusets exist

[Severin Gehwolf]

On Tue, 22 Sep 2020 11:11:36 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Hi,
> 
> can I please have a review (or an idea for a better fix) for this PR?
> 
> If a tool like [cpuset](https://github.com/lpechacek/cpuset) is used to manually create and manage
> [cpusets](https://man7.org/linux/man-pages/man7/cpuset.7.html) the cgroups detections will be confused and crash in a
> debug build or behave unexpectedly in a product build.  The problem is that the additionally mounted cpuset will be
> interpreted as if it was belonging to Cgroup controller: $ grep cgroup /proc/self/mountinfo
> 36 25 0:30 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:9 - tmpfs tmpfs ro,mode=755
> 49 36 0:43 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:23 - cgroup cgroup rw,memory
> 50 36 0:44 / /sys/fs/cgroup/rdma rw,nosuid,nodev,noexec,relatime shared:24 - cgroup cgroup rw,rdma
> ...
> 43 36 0:37 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,cpuset
> 121 32 0:37 / /cpusets rw,relatime shared:69 - cgroup none rw,cpuset
> The current fix solves this problem for manually created cpusets which don't have a "mount source" but this is yet
> another heuristic. I'm open to better solutions for detecting cpusets which don't don't belong to a Cgroup.
> Thanks,
> Volker

Did you run container tests with this?

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

PR: https://git.openjdk.java.net/jdk/pull/295