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