runtime: checkdead fires due to suspected race in the Go runtime when GOMAXPROCS=1 on AWS [1.19 backport]

[prattmic]

@prattmic requested issue #59600 to be considered for backport to the next 1.19 minor release.

@gopherbot Please open a backport issue to 1.20.

Quoting @SuperQ :

Is it possible to get this bugfix backported to 1.20? It is affecting users of Prometheus monitoring as we default GOMAXPROCS=1 for the node_exporter to reduce problems with data races in the Linux kernel.

Quoting @prattmic:

@gopherbot Please open a backport to 1.19. This issue is not new in 1.20, and potentially affects users with GOMAXPROCS=1.

[gopherbot]

Change https://go.dev/cl/504396 mentions this issue: [release-branch.go1.19] runtime: resolve checkdead panic by refining startm lock handling in caller context

[prattmic]

On closer look, I think that this issue is new in 1.20. Specifically, the issue was due to a critical section in injectglist where we allocate a P, unlock sched.lock (allowing checkdead to run), and then later in startm lock sched.lock again to actually start the M to use the P.

This was introduced in https://go-review.googlesource.com/c/go/+/389014/8/src/runtime/proc.go#3186. Prior to that CL, the P was acquired in startm with sched.lock held the whole time.

Thus I believe we can retract this cherry-pick request.

[SuperQ]

Yes, we only noticed the issue with 1.20.