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

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root
From:       Kevin Walls <kevinw () openjdk ! org>
Date:       2024-02-29 15:21:57
Message-ID: 6A-kdivyIHWO4KB2O187mLhWgX68RJdBpPOnKU6AtUM=.a3843ef4-803f-4201-9078-955b0635b31a () github ! com
[Download RAW message or body]

On Wed, 28 Feb 2024 20:02:39 GMT, jdoylei <duke@openjdk.org> wrote:

> If I understand the code change for this PR, I think it will change the behavior in \
> this scenario, because `findSocketFile` will have `pid == ns_pid`, and now will use \
> /tmp instead of `/proc/<pid>/root/tmp`, based on `findTargetProcessTmpDirectory`. 
> We are lucky currently that the only place the current OpenJDK 17 code checks `pid \
> == ns_pid` is the `createAttachFile` catch block that runs if \
> `/proc/<pid>/cwd/.attach_pid<ns_pid>` can't be created, since as long as \
> `/proc/<pid>/cwd` works, we are fine. But the `pid != ns_pid` check there makes an \
> assumption that if the process namespace is the same, the root filesystem is the \
> same and /tmp can be used, so this catch block wouldn't work if we were to hit it \
> in our scenario. I think propagating this catch block logic into `findSocketFile` \
> will break our scenario - it will force using `/tmp/.java_pid<ns_pid>` and that \
> won't work. 
> Could the `findSocketFile` logic be made more robust to the different \
> namespace/filesystem scenarios? E.g. attempt `/proc/<pid>/root` first? Or perhaps \
> there is a way (not `pid != ns_pid`) to more accurately determine whether / and \
> `/proc/<pid>/root` are the same filesystem and /tmp is OK?

That is certainly worth capturing in a new JBS bug for investigating a further \
change.  If you can't log one, I'll use the information here to do that, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1971364928


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