tree f59ae5186dfe23bc293fe8990af9edf72655fd98
parent ee94431c133a90ca5c3c5ebbebcb019c60258dac
author Cherry Zhang <cherryyz@google.com> 1547651407 -0500
committer Ian Lance Taylor <iant@golang.org> 1547691222 +0000

runtime: dropg before CAS g status to _Grunnable/_Gwaiting

Currently, we dropg (which clears gp.m) after we CAS the g status
to _Grunnable or _Gwaiting. Immediately after CASing the g status,
another thread may CAS it to _Gscan status and scan its stack.
With precise stack scan, it accesses gp.m in order to switch to g
and back (in doscanstackswitch). This races with dropg. If
doscanstackswitch reads gp.m, then dropg runs, when we restore
the m at the end of the scan it will set to a stale value. Worse,
if dropg runs after doscanstackswitch sets the new m, gp will be
running with a nil m.

To fix this, we do dropg before CAS g status to _Grunnable or
_Gwaiting. We can do this safely if we are CASing from _Grunning,
as we own the g when it is in _Grunning. There is one case where
we CAS from _Gsyscall to _Grunnable. It is not safe to dropg when
it is in _Gsyscall, as precise stack scan needs to read gp.m in
order to signal the m. So we need to introduce a transient state,
_Gexitingsyscall, between _Gsyscall and _Grunnable, where the GC
should not scan its stack.

In is a little unfortunate that we have to add another g status.
We could reuse an existing one (e.g. _Gcopystack), but it is
clearer and safer to just use a new one, as Austin suggested.

Change-Id: I02d49b0b99416e5dce26682329a0fbf5e1578b26
Reviewed-on: https://go-review.googlesource.com/c/158157
Reviewed-by: Ian Lance Taylor <iant@golang.org>