Prlimit Unit Test fail on s390x with go1.21.5

[Davo911]

What happened:
Unit tests prlimit_test.go fails on s390x wiht go1.21

What you expected to happen:
Suceed

How to reproduce it (as minimally and precisely as possible):
make test-unit

Additional context:
Part of the error output:

E0430 13:53:06.524168   21816 prlimit.go:155] failed to kill the process; <nil>
•E0430 13:53:06.548591   21816 prlimit.go:177] faker failed output is:
E0430 13:53:06.548621   21816 prlimit.go:178]
E0430 13:53:06.548634   21816 prlimit.go:179]
E0430 13:53:06.548694   21816 prlimit.go:155] failed to kill the process; os: process already finished
••••

Summarizing 1 Failure:
  [FAIL] Process Limits exec [It] command success with real limits
  /root/go/src/kubevirt.io/containerized-data-importer/pkg/system/prlimit_test.go:48

Ran 7 of 7 Specs in 2.828 seconds
FAIL! -- 6 Passed | 1 Failed | 0 Pending | 0 Skipped
--- FAIL: TestPrLimit (2.83s)
=== RUN   TestHelperProcess
--- PASS: TestHelperProcess (0.00s)
FAIL
FAIL	kubevirt.io/containerized-data-importer/pkg/system	2.852s

Workaround:

• bump go version in the bazel builder to 1.22
• remove -coverprofile flag from test command

Environment:

• ported bazel builder image used
• go version 1.21.5

[Davo911]

It appears that the test case "command success with real limits" is failing due to the memory limit set for the process.

The test case (added in this PR) sets a memory limit of 1 << 30 (approximately 1GB) for the process, apparently as a precaution to protect against denial of service attacks that could be caused by malicious images.

However, on our s390x machine, the test case only passes when we increase this limit to 1 << 31 (approximately 2GB). This suggests that the process is trying to use more than 1GB of memory, which is causing the test case to fail with the original limit.

Weirdly enough this seems not be the case with other go versions, tested with go1.22.0 and go1.20.13

[cfilleke]

That kind of discrepancy almost suggests that go 1.21 libraries do an incorrect low level malloc for s390x, but that 1.22 corrects this.

[aglitke]

/assign @akalenyu

[akalenyu]

Sounds like golang/go#64468 could be related. I was meaning to bump to 1.22 anyhow though