runtime: fix lock rank for work.spanSPMCs.lock

Currently this lock is treated like a leaf lock, but it's not one. It
can acquire the globalAlloc lock via fixalloc and persistentalloc.

This means we need to figure out where it can be acquired. In general,
it can be acquired by any write barrier, which is already incredibly
broad. AFAICT, it can't be acquired directly otherwise, except when
destroying a spanSPMC during procresize, in which case we'll be holding
sched.lock.

Fixes #75916.

Change-Id: I2da1f5b82c750bf4e8d6a8a562046b9a17fd44be
Reviewed-on: https://go-review.googlesource.com/c/go/+/717500
Reviewed-by: Michael Pratt <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>

Author: mknyszek

src/runtime/lockrank.go

@@ -199,6 +199,7 @@ func gcinit() {
 	lockInit(&work.assistQueue.lock, lockRankAssistQueue)
 	lockInit(&work.strongFromWeak.lock, lockRankStrongFromWeakQueue)
 	lockInit(&work.wbufSpans.lock, lockRankWbufSpans)
+	lockInit(&work.spanSPMCs.lock, lockRankSpanSPMCs)
 	lockInit(&gcCleanups.lock, lockRankCleanupQueue)
 }
 
@@ -352,7 +353,7 @@ type workType struct {
 	//
 	// Only used if goexperiment.GreenTeaGC.
 	spanSPMCs struct {
-		lock mutex // no lock rank because it's a leaf lock (see mklockrank.go).
+		lock mutex
 		all  *spanSPMC
 	}
 

src/runtime/mgc.go

@@ -196,6 +196,9 @@ defer,
 # xRegState allocator
 sched < xRegAlloc;
 
+# spanSPMCs allocator and list
+WB, sched < spanSPMCs;
+
 # Span allocator
 stackLarge,
   stackpool,
@@ -209,7 +212,7 @@ stackLarge,
 # Pinner bits might be freed by the span allocator.
 mheap, mspanSpecial < mheapSpecial;
 # Fixallocs
-mheap, mheapSpecial, xRegAlloc < globalAlloc;
+mheap, mheapSpecial, xRegAlloc, spanSPMCs < globalAlloc;
 
 # Execution tracer events (with a P)
 hchan,