Commit a4a57bb4 authored by Austin Clements's avatar Austin Clements

runtime: prevent race between setNextBarrierPC and sigprof

Currently, setNextBarrierPC manipulates the stack barriers without
acquiring the stack barrier lock. This is mostly okay because
setNextBarrierPC also runs synchronously on the G and prevents safe
points, but this doesn't prevent a sigprof from occurring during a
setNextBarrierPC and performing a traceback.

Given that setNextBarrierPC simply sets one entry in the stack barrier
array, this is almost certainly safe in reality. However, given that
this depends on a subtle argument, which may not hold in the future,
and that setNextBarrierPC almost never happens, making it nowhere near
performance-critical, we can simply acquire the stack barrier lock and
be sure that the synchronization will work.

Updates #12528. For 1.5.3.

Change-Id: Ife696e10d969f190157eb1cbe762a2de2ebce079
Reviewed-on: https://go-review.googlesource.com/18022
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
parent 90a68935
...@@ -305,7 +305,9 @@ func nextBarrierPC() uintptr { ...@@ -305,7 +305,9 @@ func nextBarrierPC() uintptr {
//go:nosplit //go:nosplit
func setNextBarrierPC(pc uintptr) { func setNextBarrierPC(pc uintptr) {
gp := getg() gp := getg()
gcLockStackBarriers(gp)
gp.stkbar[gp.stkbarPos].savedLRVal = pc gp.stkbar[gp.stkbarPos].savedLRVal = pc
gcUnlockStackBarriers(gp)
} }
// gcLockStackBarriers synchronizes with tracebacks of gp's stack // gcLockStackBarriers synchronizes with tracebacks of gp's stack
......
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