/ go Public
runtime: check use of osyield in signal handlers #52672
Issues related to the Go compiler and/or runtime.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
The SIGPROF handler uses
runtime.osyieldto spin while waiting for exclusive access to the profiling buffer. In the discussion of https://go.dev/cl/400795, @mknyszek questioned whether that was safe. I'm not sure that it is.
I see that on many OSes (Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Dragonfly) that function does a
sched_yield(2)syscall, which is not one of the syscalls listed in signal-safety(7) as being required by POSIX to be safe to call from signal handlers.
On top of that, the change in Go 1.18 to use
timer_create(2)on Linux for CPU profiling means that many SIGPROF deliveries are now thread-targeted (versus
setitimer(2)'s process-targeted signals), which may have opened the possibility of a process handling multiple overlapping SIGPROF deliveries (on separate threads).
Let's make sure the
runtime.osyieldcalls are safe in that context, and write down why.
Here's some of the code in question: https://github.com/golang/go/blob/go1.18.1/src/runtime/cpuprof.go#L123-L129
The text was updated successfully, but these errors were encountered: