runtime: lock order violation between gscan and profInsert after CL 544195 #64706
Description
#!watchflakes
post <- builder ~ `.*-staticlockranking` && log ~ `lock ordering problem` && log ~ `profInsert`
https://build.golang.org/log/9ef94ae07bd07605e17fcd241ef0d38d5064b41f
https://build.golang.org/log/3f80d959a6cc683334f8521b8a3b002dda1bd6b3
https://build.golang.org/log/a5bfdd06fa69808fe6378b412610e65b06ddd8ff
Taking profInsert after gscan is indeed an explicit violation based on our defined lock order: https://cs.opensource.google/go/go/+/master:src/runtime/mklockrank.go;l=125-138;drc=23c0d30244d5e38d928e68661bf39458eb85d2b2.
That said, I am currently confused about the entire STACKGROW category (long day, perhaps). As far as I can tell, the gscan "lock" is only ever held from the system stack, so I don't understand how any of these other locks could "grow the stack", or what exactly we are protecting against.