runtime: “lock ordering problem” between `trace` and `wbufSpans`

[bcmills]

2022-05-08T17:28:26-1b86ef4/linux-amd64-staticlockranking:

37363  ======
0 : trace 28 0x8485a0
1 : wbufSpans 39 0x840770
fatal error: lock ordering problem

(attn @golang/runtime; see previously #41021)

[rhysh]

If I understand the log correctly, this would mean that lockrank.go would not allow write barriers when an M is holding trace.lock. The call to gcWriteBarrierCX comes from https://github.com/golang/go/blob/1b86ef47de/src/runtime/trace.go#L410, setting trace.strings = nil. But that line also exists in go1.18.1, still within the section that holds trace.lock https://github.com/golang/go/blob/go1.18.1/src/runtime/trace.go#L368.

Another "missing, but valid, edge on the wbufSpans lock"?

I don't see lockRankTrace in the list for lockRankMHeap https://github.com/golang/go/blob/1b86ef47de/src/runtime/lockrank.go#L244 , but I also don't see anywhere in runtime.StopTrace that allocates .. only write barriers.

[mknyszek]

@rhysh Yeah, this just looks like a missing edge to me. The write barrier path can acquire the mheap lock in order to allocate a new write barrier buffer.

[gopherbot]

Change https://go.dev/cl/405476 mentions this issue: runtime: add lock partial order edge for trace and wbufSpans and mheap