cmd/compile: regression in race-instrumentation causes deadline races

[dsnet]

8b3194a attempts to fix #17449.

In a large RPC test, this change causes a GET request to report a "deadline exceeded error" immediately with some high probability even though the deadline has not passed.

Presently, I do not have a smaller reproduction that I can provide. Information is sparse; more to come.

Anyone opposed to reverting?

/cc @mdempsky @Dhananjay92

[JayNakrani]

As a temporary fix, I am okay with reverting. Can you point me to the test though?

[dsnet]

The test is proprietary. I have suspicions that it has to deal with different regression caused by https://go-review.googlesource.com/#/c/31173/, which causes similar failures. It's possible that CL/31317 caused a bug and your CL simply made them occur more frequently.

[mdempsky]

@dsnet That CL only affects -race builds. Can you confirm the internal test is using -race?

It seems unlikely to be the actual problem (the new code is more intuitively correct IMO), but I'm okay with reverting it if we can't find another fix.

[JayNakrani]

As discussed in #17559, the deadline_exceeded regression is because of race between abortPendingRead() and backgroundRead() net.Conn implementation not respecting semantics. The race instrumentation change is not playing any role in this. I sent out https://golang.org/cl/31755 which I believe takes care of that race and another deadlock.

[dsnet]

The source of this issue is due to a buggy implementation of net.Conn that started exhibit failures once https://go-review.googlesource.com/#/c/31173/ landed.

https://go-review.googlesource.com/#/c/31317/ was incorrectly identified as the cause because flakiness in whether the problem exhibited itself caused the bisect to incorrectly identify a slightly later CL as the issue.