runtime: fix lockrank ordering for pinner implementation

The new Pinner API's implementation imposes some partial-orders that are safe but previously did not exist between a mspanSpecial, mheapSpecial, and mheap. Fix that up in the lock ranking. For #46787. Change-Id: I51cc8f7f069240caeb44d749bed43515634f4814 Reviewed-on: https://go-review.googlesource.com/c/go/+/496193 Run-TryBot: Michael Knyszek <[email protected]> Reviewed-by: David Chase <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
golang · May 19, 2023 · 78df00d · 78df00d
1 parent f283cba
commit 78df00d
Show file tree

Hide file tree

Showing 2 changed files with 17 additions and 13 deletions.
diff --git a/src/runtime/lockrank.go b/src/runtime/lockrank.go
diff --git a/src/runtime/mklockrank.go b/src/runtime/mklockrank.go
@@ -110,9 +110,8 @@ allg,
 # Below MALLOC is the malloc implementation.
 < fin,
   gcBitsArenas,
-  mheapSpecial,
-  mspanSpecial,
   spanSetSpine,
+  mspanSpecial,
   MPROF;
 
 # Memory profiling
@@ -159,6 +158,11 @@ stackLarge,
 # Above mheap is anything that can call the span allocator.
 < mheap;
 # Below mheap is the span allocator implementation.
+#
+# Specials: we're allowed to allocate a special while holding
+# an mspanSpecial lock, and they're part of the malloc implementation.
+# Pinner bits might be freed by the span allocator.
+mheap, mspanSpecial < mheapSpecial;
 mheap, mheapSpecial < globalAlloc;
 
 # Execution tracer events (with a P)