runtime/secret: restore goroutine behavior to proposal

During review of CL 704615, a suggestion was made that spawning a
goroutine inside a call to secret.Do result in a panic. I agreed with
this at the time, but had missed that this had been extensively
discussed on the proposal. Revert the behavior back to what was agreed
upon.

Change-Id: Ifaa9e24bd03ecbd870ae2217137d1a9527c96842
Reviewed-on: https://go-review.googlesource.com/c/go/+/728920
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This commit is contained in:
Daniel Morsing 2025-12-10 10:07:56 +00:00 committed by David Chase
parent 6455afbc6f
commit 63fced531c
2 changed files with 1 additions and 5 deletions

View File

@ -5286,10 +5286,6 @@ func malg(stacksize int32) *g {
// The compiler turns a go statement into a call to this.
func newproc(fn *funcval) {
gp := getg()
if goexperiment.RuntimeSecret && gp.secret > 0 {
panic("goroutine spawned while running in secret mode")
}
pc := sys.GetCallerPC()
systemstack(func() {
newg := newproc1(fn, gp, pc, false, waitReasonZero)

View File

@ -28,7 +28,7 @@ import (
// - Currently only supported on linux/amd64 and linux/arm64. On unsupported
// platforms, Do will invoke f directly.
// - Protection does not extend to any global variables written by f.
// - Any attempt to launch a goroutine by f will result in a panic.
// - Protection does not extend to any new goroutines made by f.
// - If f calls runtime.Goexit, erasure can be delayed by defers
// higher up on the call stack.
// - Heap allocations will only be erased if the program drops all