Commit 69614c0d authored by Austin Clements's avatar Austin Clements

runtime: give useful failure message on mlock failure

Currently, we're ignoring failures to mlock signal stacks in the
workaround for #35777. This means if your mlock limit is low, you'll
instead get random memory corruption, which seems like the wrong
trade-off.

This CL checks for mlock failures and panics with useful guidance.

Updates #35777.

Change-Id: I15f02d3a1fceade79f6ca717500ca5b86d5bd570
Reviewed-on: https://go-review.googlesource.com/c/go/+/210098
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
parent 0915a19a
......@@ -59,5 +59,13 @@ func osArchInit() {
}
func mlockGsignal(gsignal *g) {
mlock(gsignal.stack.hi-physPageSize, physPageSize)
if err := mlock(gsignal.stack.hi-physPageSize, physPageSize); err < 0 {
printlock()
println("runtime: mlock of signal stack failed:", -err)
if err == -_ENOMEM {
println("runtime: increase the mlock limit (ulimit -l) or")
}
println("runtime: update your kernel to 5.4.2 or later")
throw("mlock failed")
}
}
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment