On Thu, 6 May 2021 at 15:57, Warner Losh <imp@xxxxxxxxxx> wrote: > malloc, on the other hand, involves taking out a number of mutexes > and similar things to obtain the memory, which may not necessarily > be safe in all the contexts system calls can be called from. System > calls are, typically, async safe and can be called from signal handlers. > alloca() is async safe, while malloc() is not. So changing the calls > from alloca to malloc makes calls to system calls in signal handlers > unsafe and potentially introducing buggy behavior as a result. malloc() should definitely be fine in this context. The syscall emulation is called after the cpu_loop() in bsd-user has called cpu_exec(). cpu_exec() calls into the JIT, which will malloc all over the place if it needs to in the course of JITting things. This code should never be being called from a (host) signal handler. In upstream the signal handling code for bsd-user appears to be missing entirely. For linux-user when we take a host signal we merely arrange for the guest to take a guest signal, we don't try to execute guest code directly from the host handler. (There are some pretty hairy races in emulated signal handling: we did a big overhaul of the linux-user code in that area a while back. If your bsd-user code doesn't have the 'safe_syscall' stuff it probably needs it. But that's more about races between "guest code wants to execute a syscall" and "incoming signal" where we could fail to exit EINTR from an emulated syscall if the signal arrives in a bad window.) thanks -- PMM