RFR: 8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved [v9]

[Thomas Stuefe]

On Thu, 6 Jun 2024 07:59:32 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> To clarify, the current revised patch does **NOT** add any if-cond to check UEK, instead it enhances the check of the readiness of `MADV_POPULATE_WRITE` on `5.14 and beyond` (stated by Linux kernel official docs). In addition, the two test cases failing on UEK kernel can also be a justification that the condition of having `supportMadvPopulateWrite` needs to be strengthened. We could not say that it is a problem only exists in UEK kernel, in theory every distros could backport part of `MADV_POPULATE_WRITE` function from 5.14 to previous version or reuse any madv op code there, which is out of our control or our testing coverage.

The problem does not exist for other kernels if they don't break binary compatibility with the mainline kernel. Which UEK does by introducing new madvise flags that occupy numerical slots that should be unoccupied. A clean downstream kernel can downport MADV_POPULATE_WRITE without problems since there will be no numerical clash.

Now, even if a clean downstream kernel were to downport support for MADV_POPULATE_WRITE, we would not benefit from it.

> 
> Therefore, having the >=5.14 check can be a safer way to all.

The real issue is a clash with UEK-proprietary flags. Adding proprietary flags is not a good practice. More clashes are waiting to happen, including clashes with the far more dangerous MADV_DOEXEC. 

I worry that someone, at some point, may add an innocous patch in the future using one of these and trigger usage of MADV_DOEXEC. I would feel better if we had clear safeguards to prevent that.

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

PR Comment: https://git.openjdk.org/jdk/pull/18592#issuecomment-2151715722