• Anthony Martin's avatar
    runtime: call rfork on scheduler stack on Plan 9 · 9f012e10
    Anthony Martin authored
    A race exists between the parent and child processes after a fork.
    The child needs to access the new M pointer passed as an argument
    but the parent may have already returned and clobbered it.
    
    Previously, we avoided this by saving the necessary data into
    registers before the rfork system call but this isn't guaranteed
    to work because Plan 9 makes no promises about the register state
    after a system call. Only the 386 kernel seems to save them.
    For amd64 and arm, this method won't work.
    
    We eliminate the race by allocating stack space for the scheduler
    goroutines (g0) in the per-process copy-on-write stack segment and
    by only calling rfork on the scheduler stack.
    
    LGTM=aram, 0intro, rsc
    R=aram, 0intro, mischief, rsc
    CC=golang-codereviews
    https://golang.org/cl/110680044
    9f012e10
sys_plan9_386.s 4.33 KB