runtime: frequent TestSegv failures since 2021-10-26

[bcmills]

@prattmic, possibly related to CL 339989 / #47522?

greplogs --dashboard -md -l -e 'FAIL: TestSegv' --since=2021-10-01

2021-10-27T13:12:49-cfb5321/illumos-amd64
2021-10-27T08:50:27-bdefb77/illumos-amd64
2021-10-27T08:50:27-bdefb77/solaris-amd64-oraclerel
2021-10-27T05:33:58-ca5f65d/illumos-amd64
2021-10-26T23:12:17-13eccaa/illumos-amd64
2021-10-26T23:12:17-13eccaa/solaris-amd64-oraclerel
2021-10-26T23:06:10-e5c5125/illumos-amd64
2021-10-26T23:06:10-e5c5125/solaris-amd64-oraclerel
2021-10-26T22:05:53-80be4a4/illumos-amd64
2021-10-26T22:05:53-80be4a4/solaris-amd64-oraclerel
2021-10-26T21:32:57-86f6bf1/darwin-amd64-race
2021-10-26T21:32:57-86f6bf1/illumos-amd64

[cuonglm]

I think since https://go-review.googlesource.com/c/go/+/339990

CL https://go-review.googlesource.com/c/go/+/339989 causes windows-arm64-10 builder fails.

[bcmills]

Filed the windows-arm64-10 issue separately as #49188.

[gopherbot]

Change https://golang.org/cl/359254 mentions this issue: runtime: disable TestSegv on darwin, illumos, solaris

[bcmills]

Hmm, looks like relaxing the check didn't completely solve the problem:

greplogs --dashboard -md -l -e 'FAIL: TestSegv' --since=2021-10-28T16:54:00

2021-10-28T16:54:58-6bd0e7f/linux-arm-aws

[bcmills]

linux-arm-aws is the only one that appears to still be flaky:

greplogs --dashboard -md -l -e '(?ms)TestSegv.*unexpectedly saw "runtime: "'

2021-11-02T20:47:30-b246873/linux-arm-aws
2021-11-02T17:01:14-62b29b0/linux-arm-aws
2021-10-28T16:54:58-6bd0e7f/linux-arm-aws

[aclements]

This looks like the signal is landing while we're in the VDSO, presumably executing a kernel-provided atomic for casgstatus.

@prattmic, you looked at and fixed a few similar issues recently (e.g., 86f6bf1). Any insights on this one?

[aclements]

Yeah, the "unknown PC" is in the kernel-provided CAS implementation. The problem may just be that we're entirely missing the vdsoSP protection around the VDSO cas call (presumably the same thing applies to memory_barrier<>, too).

[prattmic]

Yes, I believe that is the case. I'll get those covered as well.