whitelist ubuntu 20.04 kernel for the mlock of signal stack failed issue

[juliantaylor]

What version of Go are you using (go version)?

1.14.2

Golang has a check on startup for issue gh-35777

runtime: mlock of signal stack failed: 12
runtime: increase the mlock limit (ulimit -l) or
runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+
fatal error: mlock failed

This also triggers on ubuntu 20.04 which currently has a 5.4.34 kernel.
Likely golang does not properly detect this as the version number in uname -a is:
5.4.0-29-generic as ubuntu maintains its own stable kernels and does not bump the version numbers when upstream does.
But they have the fix https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=59c4bd853abcea95eccc167a7d7fd5f1a5f47b98 included:

$ apt source linux-source-5.4.0
$ cd linux-5.4.0/
$ grep "Don't cache access to fpu_fpregs_owner_ctx" -r
debian/changelog:    - x86/fpu: Don't cache access to fpu_fpregs_owner_ctx
debian.master/changelog:    - x86/fpu: Don't cache access to fpu_fpregs_owner_ctx

To save some users the trouble of having to change their system configuration, it would be good to whitelist the ubuntu kernels too.

[juliantaylor]

the ubuntu kernel was fixed in version 5.4.0-8.11

[martisch]

Relevant: #37436
https://github.com/golang/go/wiki/LinuxKernelSignalVectorBug

Please check/make sure that the program was compiled with go1.14.2 since that particular error message is not in go1.14 release branch anymore and go1.14.2 has been cut after that CL:
https://go-review.googlesource.com/c/go/+/223417/3/src/runtime/os_linux_x86.go
96745b9

go version -m ./mybinary will show the version a binary was compiled with for ./mybinary.

If this is not go1.14.2 please recompile and try to run the binary again.

[juliantaylor]

I actually encountered the issue when building a go program with the golang:1.14 docker image today, unfortunately running go version in it does not report the patch version, I just assumed it would be the latest.

But if you have fixed the startup failure independent of the detected kernel version then this issue is obsolete and you can close it. I only checked that the version check was still there in the 1.14 branches code but did not understand that the change you linked also removed the startup failure.