[jdk21u-dev] RFR: 8337966: (fs) Files.readAttributes fails with Operation not permitted on older docker releases [v3]

[Martin Balao]

On Wed, 4 Sep 2024 18:19:16 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This seems OK as a fix to improve compatibility with older JDK 21 versions that didn't use `statx`. Somebody else should review it too, though.
>
>> This seems OK as a fix to improve compatibility with older JDK 21 versions that didn't use `statx`. Somebody else should review it too, though.
> 
> Thank you the review. @AlanBateman , @bplb could you please look at the changes for 21u.

@alexeybakhtin Thanks for looking into this problem. I've followed the discussion (JDK main line and 21u-dev PRs) and the proposed changes. I have some concerns.

As @AlanBateman mentioned [here](https://github.com/openjdk/jdk/pull/20484#issuecomment-2316814125), `EPERM` seems to be undocumented for `statx` and that's not ideal. Is this stable and consistent across all Kernel/glibc versions? Is there another reason for the implementation to return `EPERM`? If this is true, these cases will be penalized with a double-call (statx, stat). Is there another way to check what an active filter is blocking?

With the proposed code, when running in a Docker container —or, more generically, with a seccomp filter blocking statx— each call will be penalized going through `statx` and `stat` because the unavailability of `statx` due to a filter is never recorded. Recording this would require handling contention.

I personally think that the problem has to be fixed on Docker's side, but I understand that this was a problematic change of behavior in stable releases. @jerboaa 8316304 is documented as an enhancement. Will something be broken if we back it off from 21u and 17u?

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/951#issuecomment-2333363863