]> Cypherpunks repositories - gostls13.git/commit
runtime: add a barrier after a new span is allocated
authorCherry Zhang <cherryyz@google.com>
Mon, 18 May 2020 18:14:11 +0000 (14:14 -0400)
committerCherry Zhang <cherryyz@google.com>
Thu, 21 May 2020 14:31:36 +0000 (14:31 +0000)
commitc53b2bdb35c5339df35b53c8fbf34e5cbede081f
treee86ff517614a7b8fae5447b82fcbab159acc4ce7
parent567556d78657326c99b8fa84ec2a5ee511a0941b
runtime: add a barrier after a new span is allocated

When copying a stack, we
1. allocate a new stack,
2. adjust pointers pointing to the old stack to pointing to the
   new stack.

If the GC is running on another thread concurrently, on a machine
with weak memory model, the GC could observe the adjusted pointer
(e.g. through gp._defer which could be a special heap-to-stack
pointer), but not observe the publish of the new stack span. In
this case, the GC will see the adjusted pointer pointing to an
unallocated span, and throw. Fixing this by adding a publication
barrier between the allocation of the span and adjusting pointers.

One testcase for this is TestDeferHeapAndStack in long mode. It
fails reliably on linux-mips64le-mengzhuo builder without the fix,
and passes reliably after the fix.

Fixes #35541.

Change-Id: I82b09b824fdf14be7336a9ee853f56dec1b13b90
Reviewed-on: https://go-review.googlesource.com/c/go/+/234478
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
src/runtime/mheap.go