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

[Ioi Lam]

On Sat, 9 Jul 2022 05:19:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> 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.

I simplified the code and restructured the comments to be interspersed with the code. Hopefully that would make the logic a little easier to understand.

Despite the large diff in cleanup_sharedmem_files(), the only actual change is to `flock` in the middle of the loop, and avoid deleting the file if the `flock` fails.

I removed this comment


// ... are removed because the resources for such a
// process should be in a different user specific directory.


and replaced it with something more comprehensive which hopefully makes more sense:


// This directory should be used only by JVM processes owned by the
// current user to store PerfMemory files. Any other files found
// in this directory may be removed.

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

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