runtime: check use of osyield in signal handlers

[rhysh]

The SIGPROF handler uses runtime.osyield to 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.osyield calls 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

[ianlancetaylor]

Pure system calls are basically always async-signal-safe.

POSIX doesn't require sched_yield to be async-signal-safe because POSIX doesn't require threads to be implemented in the kernel. But for those cases where osyield is just a system call, we are fine.

[mknyszek]

Thanks Ian. A bunch of platforms do call sched_yield through libc (or some other shared library). Presumably that's done just because we do everything through libc on those platforms, and really it's just a simple syscall under the hood. I suppose we just have to trust that and document it.

[mknyszek]

Pushing this to Go 1.22.

[bcmills]

Presumably that's done just because we do everything through libc on those platforms, and really it's just a simple syscall under the hood.

How sure are we about that, especially in the context of the race detector?
I wonder if this may be responsible for runtime/pprof deadlocks on darwin-amd64-race:

• runtime/pprof: TestCPUProfileWithFork failures with stuck writerDescriptor goroutines #59995
• runtime/pprof: test timed out in StartCPUProfile #60108

[mknyszek]

I'm certainly less sure than I used to be!