Ian Lance Taylor f41bf58736 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.
    
    Reviewed-on: https://go-review.googlesource.com/c/158157

From-SVN: r268001
2019-01-17 02:14:28 +00:00
..
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-01-09 01:23:08 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-10-08 14:21:30 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2016-07-22 18:15:38 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-10-08 14:21:30 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00
2018-09-24 21:46:21 +00:00