Comment 1:

Labels changed: added release-go1.4, repo-main, racedetector.

Status changed to Accepted.

Comment 2:

Wait-wait-wait. The fix is incorrect and all the conclusions. What is wrong here is that
race detector sees events happening on system stacks g0/gsignal. There is no possible
semantic meaning for these events. At best they will lead to degraded performance if
handled. And at worst to false positives as race detector does not see most of the
synchronization happening inside of runtime (that g0 synchronizes with curg during
mcall, for example). And if we will try to teach race detector about all that
synchronization, then it will lead to massive false negatives for user code.
Runtime code is not instrumented by compiler on purpose. The manual instrumentation in
copy/growslice/hashmaps was only happening on user gs to date. Now it happens on
g0/gsignal as we have much more Go code in runtime. The events like copy in mprof are
implementation details of runtime, they need to be ignored by race detector. And
g0/gsignal must not have race context at all.
There is a possible case when g0 executes an interesting memory access or
synchronization on behalf of a user goroutine. For example, if growslice would call onM
and do the rest of work on g0. We does not seem to have such cases now. If such case is
discovered, then race detector will need to use g->m->curg->racectx to handle such
events. But we still don't need racectx for g0.

Comment 3:

CL https://golang.org/cl/137070043 mentions this issue.

Comment 4:

This issue was closed by revision 467a6d2.

Status changed to Fixed.

Comment 5:

From dvyukov's comment in https://golang.org/cl/137070043#msg4 ("I agree that
we need something more systematic in future. But the change will complex and subtle and
can potentially severely degrade performance. I don't want to rewrite it just before
release."), it seems like the commit is just the minimum to allow copy() from a signal
handler.  I suspect we want to keep the issue open (but probably targeted towards 1.5)
to track progress on the more systematic fix?