On Thu, May 6, 2021 at 9:59 AM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Thu, 6 May 2021 at 15:57, Warner Losh <i...@bsdimp.com> 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. > Gotcha. That's the context I was trying to chase down via other vectors. > 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. > OK. Then that makes sense to me now. I'll look through the bsd-user stuff in our branch... > (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.) > Those have not yet been moved over entirely. And it was looking through those patches that gave me a health respect (fear?) of issues with mixing of host/guest signals... Warner
