src/runtime/crash_unix_test.go | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 skip flaky testcrashdumpsallthreads on mips64le

crash_unix_test.go:145: found 3 instances of main.crashDumpsAllThreadsLoop; expected 4

src/runtime/crash_unix_test.go | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 skip flaky testcrashdumpsallthreads on s390x

Bug: https://github.com/golang/go/issues/64650

src/runtime/os3_solaris.go | 5 4 + 1 - 0 !
src/runtime/os_aix.go | 5 4 + 1 - 0 !
src/runtime/os_darwin.go | 5 4 + 1 - 0 !
src/runtime/os_dragonfly.go | 5 4 + 1 - 0 !
src/runtime/os_linux.go | 9 4 + 5 - 0 !
src/runtime/os_netbsd.go | 5 4 + 1 - 0 !
src/runtime/os_openbsd.go | 5 4 + 1 - 0 !
src/runtime/os_plan9.go | 5 4 + 1 - 0 !
src/runtime/os_windows.go | 4 3 + 1 - 0 !
src/runtime/proc.go | 3 3 + 0 - 0 !
src/runtime/vgetrandom_linux.go | 11 9 + 2 - 0 !
src/runtime/vgetrandom_unsupported.go | 2 1 + 1 - 0 !
12 files changed, 48 insertions(+), 16 deletions(-)

 runtime: cleanup m vgetrandom state before dropping p

When an M is destroyed, we put its vgetrandom state back on the shared
list for another M to reuse. This list is simply a slice, so appending
to the slice may allocate. Currently this operation is performed in
mdestroy, after the P is released, meaning allocation is not allowed.

More the cleanup earlier in mdestroy when allocation is still OK.

Also add //go:nowritebarrierrec to mdestroy since it runs without a P,
which would have caught this bug.

Fixes #73144.
For #73141.