[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Integrated: 8286030: Avoid JVM crash when containers share the same /tmp dir
From:       Ioi Lam <iklam () openjdk ! org>
Date:       2022-07-18 4:13:38
Message-ID: cThmu1iVTrs-A-lYds6gnNhJeyjrEtvDmvWBhhZ1Rkc=.527d441e-6826-4139-b129-fc415c567329 () github ! com
[Download RAW message or body]

On Thu, 7 Jul 2022 06:01:58 GMT, Ioi Lam <iklam@openjdk.org> wrote:

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare \
> occasions, the JVM may crash when it tries to write to \
> `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do \
> the same thing (because they happen to have the same namespaced pid). 
> This patch avoids the crash by using `flock()` to allow only one of these processes \
> to write to the file. All other competing processes that fail to grab the lock will \
> give up the file and run with PerfMemory disabled. We will try to enable PerfMemory \
> for the failed processes in a follow-up RFE: \
> [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883) 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using \
> `flock()`. 
> I kept the use of `kill()` for stale file detection to be compatible with older \
> JVMs. 
> I also took the opportunity to clean up the comments and remove dead code. The old \
> code was using "shared memory resources" which sounds unclear and odd. I changed \
> the terminology to say "shared memory file" instead.

This pull request has now been integrated.

Changeset: 84f23149
Author:    Ioi Lam <iklam@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84f23149e22561173feb0e34bca31a7345b43c89
                
Stats:     324 lines in 3 files changed: 267 ins; 27 del; 30 mod

8286030: Avoid JVM crash when containers share the same /tmp dir

Reviewed-by: stuefe, sgehwolf

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

PR: https://git.openjdk.org/jdk/pull/9406


[prev in list] [next in list] [prev in thread] [next in thread]