Commit 22e57c66 authored by Austin Clements's avatar Austin Clements

runtime: make stack barrier locking more robust

The stack barrier locking functions use a simple cas lock because they
need to support trylock, but currently don't increment g.m.locks. This
is okay right now because they always run on the system stack or the
signal stack and are hence non-preemtible, but this could lead to
difficult-to-reproduce deadlocks if these conditions change in the
future.

Make these functions more robust by incrementing g.m.locks and making
them nosplit to enforce non-preemtibility.

Change-Id: I73d60a35bd2ad2d81c73aeb20dbd37665730eb1b
Reviewed-on: https://go-review.googlesource.com/17058
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIngo Oeser <nightlyone@googlemail.com>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
parent 04178728
......@@ -300,16 +300,26 @@ func setNextBarrierPC(pc uintptr) {
// This is necessary because a sigprof during barrier installation or
// removal could observe inconsistencies between the stkbar array and
// the stack itself and crash.
//
//go:nosplit
func gcLockStackBarriers(gp *g) {
acquirem()
for !atomic.Cas(&gp.stackLock, 0, 1) {
osyield()
}
}
//go:nosplit
func gcTryLockStackBarriers(gp *g) bool {
return atomic.Cas(&gp.stackLock, 0, 1)
mp := acquirem()
result := atomic.Cas(&gp.stackLock, 0, 1)
if !result {
releasem(mp)
}
return result
}
func gcUnlockStackBarriers(gp *g) {
atomic.Store(&gp.stackLock, 0)
releasem(getg().m)
}
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