RFR: 8286030: Avoid JVM crash when containers share the same /tmp dir [v2]

Ioi Lam iklam at openjdk.org
Sat Jul 9 05:22:44 UTC 2022


On Fri, 8 Jul 2022 07:08:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @tstuefe comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 796:
> 
>> 794:     if (!is_locked_by_another_process) {
>> 795:       if ((pid == os::current_process_id()) ||
>> 796:           (kill(pid, 0) == OS_ERR && (errno == ESRCH || errno == EPERM))) {
> 
> Thinking about this, I now was confused. AFAICS this code is only ever called from `mmap_create_shared` with the directory containing our own pid. I do not see this called for PIDs from other processes. Why do we handle that case? Or am I overlooking something?

The current JVM process only cleans up stale files in the current user's own directory. I.e., /tmp/hsperfdata_bob/. However,  when we see a file like /tmp/hsperfdata_bob/1234, it's possible that

- 1234 was a JVM process created by bob, but this process died without cleaning up
- A new process 1234 is now running, but it belongs to a different user, john

So if `kill(1234, 0)` fails, the JVM concludes that, "/tmp/hsperfdata_bob/1234 must belong to a terminated JVM process owned by bob".

I think this is the intention of the code, in spite of what the comment says above the `kill` call.

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

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


More information about the serviceability-dev mailing list