runtime: fix another lock ordering problem
https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/
8753622336585847105/+/u/step/11/log/2
shows a staticlockranking crash with pollcache (defaulted to LEAF)
being held during a write barrier, which got unlucky and acquired
wbufSpans, triggering a lock ordering throw.
My change in https://go-review.googlesource.com/c/go/+/570335/13/src/runtime/netpoll.go
around line 700 caused batching of many write barriers on the first
call rather than having just a few write barriers on each call,
making the crash much more likely, but the ordering problem
appears to have always existed. We just never allocated enough
pollDescs to trigger it.
Change-Id: Icb5e8340a5027dd4f7535a5ef02b2868476539e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/571195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>