runtime: call rfork on scheduler stack on Plan 9
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
Showing
Please
register
or
sign in
to comment