runtime: remove the mlock hack in Go 1.15

[DanielShaulov]

The resolution to #35777 was to mlock the top of stack on "affected" kernels. But then it was discovered that major distros use kernels that appear by the version number to be affected but are actually patched (#37436). It was also discovered that docker under systemd has a very low limit on mlocked pages (same issue). The resolution for that was to stop reporting failures of mlock and delay the warning until a crash is caught.

There is a TODO comment in the code to remove all of that hack for Go 1.15, since unpatched kernels are unlikely to be encountered, but Go 1.15 is due to be released in a short time and the code is still there.

I think it is important to remove the workaround since Ubuntu 20.04 LTS uses a patched 5.4.0 kernel. This means that any user on Ubuntu 20.04 will still unnecessarily mlock pages, and if he runs in a docker container, that warning will be displayed for every crash, disregarding the fact that his kernel is not really buggy. So those users might be sent on a wild goose chase trying to understand and read all this info, and it will have nothing to do with their bug, probably for the entirety of Ubuntu 20.04 life cycle.

Relevant code is in src/runtime/os_linux_x86.go

[ALTree]

There is a TODO comment in the code to remove all of that hack for Go 1.15 [...] but Go 1.15 is due to be released in a short time and the code is still there.

Can you link where this TODO is? The only relevant comment I found was on CL 223121, in the runtime/panic.go file, but it says:

// TODO(austin): Remove this after Go 1.15 when we remove the
// mlockGsignal workaround

and "after Go 1.15" means for Go 1.16.

[randall77]

@aclements

[nemith]

Since the kernel detection is done based off of major/minor numbers we actually have to apply a patch to internal builds of the compiler to include our own kernel builds which are not affected but fall in the affected range. I would love for this to be removed or at least optionally bypassed

[networkimprov]

I don't think this needs further info from the author to be actionable...

@gopherbot remove WaitingForInfo

[aclements]

@nemith , can you explain why you need to patch the compiler? As of Go 1.14.1, the only effect of an mlock failure is an additional message if there's an uncaught panic, so I don't understand why that requires patching.

[ianlancetaylor]

If there is a way to detect the patched kernel, perhaps by reading /proc/version, I think we could implement that safely enough in 1.15.

[networkimprov]

Re kernel version sources, see this and comments immediately preceding it: #37436 (comment)

[aclements]

There's one deciding factor here: is the kernel patch widespread enough that the workaround is no longer necessary? I'm sure all the distros have it, but people aren't necessarily on top of upgrading their kernels. Unfortunately, I have no idea how to figure out the answer to this, and I think we should be fairly conservative about this given the nature of the kernel bug.

[lootch]

On 7/13/20, Daniel Shaulov ***@***.***> wrote: The resolution to #35777 was to `mlock` the top of stack on "affected" kernels. But then it was discovered that major distros use kernels that appear by the version number to be affected but are actually patched (#37436).

It may be a bitch to do and contrary to Go best practices, but an "alert" (nag?) mode that notifies users that the kernel they run under needs a patch, or even better, gives them the ability to check if their kernel needs attention may be the only politically correct answer here. Something that can easily be removed once the user has attended to it. Or, perhaps better, something they can add as part of the installation and drop as soon as possible. Lucio.