[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread safety of coroutine-sigaltstack

From: Max Reitz
Subject: Re: Thread safety of coroutine-sigaltstack
Date: Fri, 22 Jan 2021 11:16:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 22.01.21 11:14, Peter Maydell wrote:
On Fri, 22 Jan 2021 at 08:50, Max Reitz <mreitz@redhat.com> wrote:

On 20.01.21 18:25, Laszlo Ersek wrote:


A simple grep for SIGUSR2 seems to indicate that SIGUSR2 is not used by
system emulation for anything else, in practice. Is it possible to
dedicate SIGUSR2 explicitly to coroutine-sigaltstack, and set up the
action beforehand, from some init function that executes on a "central"
thread, before qemu_coroutine_new() is ever called?

I wrote a patch to that effect, but just before sending I wondered
whether SIGUSR2 cannot be registered by the “guest” in user-mode
emulation, and whether that would then break coroutines from there on.

(I have no experience dealing with user-mode emulation, but it does look
like the guest can just register handlers for any signal but SIGSEGV and

Yes, SIGUSR2 is for the guest in user-emulation mode. OTOH do we
even use the coroutine code in user-emulation mode? Looking at
the meson.build files, we only add the coroutine_*.c to util_ss
if 'have_block', and we set have_block = have_system or have_tools.
I think (but have not checked) that that means we will build and
link the object file into the user-mode binaries if you happen
to build them in the same run as system-mode binaries, but won't
build them in if you built the user-mode binaries as a separate
build. Which is odd and probably worth fixing, but does mean we
know that we aren't actually using coroutines in user-mode.
(Also user-mode really means Linux or BSD and I think both of
those have working ucontext.)

OK, great.  Thanks for looking that up.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]