Re: [Qemu-devel] [PATCH v2 00/16] Augment support for signal handling

[Peter Maydell]

On 15 May 2017 at 15:59, Miloš Stojanović <address@hidden> wrote:
> D. Add support for larger target signal range (RFC patches 10-16):
>
>    Add target signal mask tracking and multiplexing of target signals out
>    of the host range. The patches are marked as RFC because they introduce
>    significant new functionalities regarding signal handling in QEMU.
>
>    Currently, QEMU has a copy of the host signal and suspend masks and
>    that is usually enough, since most of the time the signal mask of the
>    target architecture is either the same length or narrower. If however
>    the signal mask is wider, then part of it won't be tracked. The signals
>    that are in the target range but out of the host range were treated like
>    faulty signals and couldn't be used. This problem is solved by enabling
>    the usage of one of the host signals as a multiplex for all the target
>    signals that are out of range. In order to have the target signal masks
>    available, tracking of target signal masks is implemented.
>
>    The rt_sigqueueinfo()/rt_tgsigqueueinfo() system calls multiplex target
>    signals by setting the si_errno value to the actual value of the signal
>    and sending the signal to a predefined host signal number.
>    The host_signal_handler() will pull out the multiplexed signals and set
>    their signal number to the correct value. The si_errno field is used
>    here but this implementation can be replaced with any other unused field
>    in the uinfo structure. Using this implementation both rt_sigqueueinfo(),
>    rt_tgsigqueueinfo(), as well as kill() (for pid > 0) and tgkill() can be
>    emulated.
>
>    The tkill() system call and kill() with the argument pid <= 0 couldn't
>    be implemented simply using this method because it requires acquiring
>    information about, and sending simultaneous signals to multiple threads
>    or processes. These functionalities are out of the scope of
>    rt_sigqueueinfo()/rt_tgsigqueueinfo().

This certainly sounds good -- can it fix our problems with clashes
between the host libc and guest libc use of signals?

I do wonder if this is opening up subtle bugs, though: if the
guest does:
  * block signal X
  * some syscall
  * unblock X

then we shouldn't interrupt the syscall if signal X arrives.
That works when we use host signal X for guest signal X because
we just block host signal X. But I don't see how it works if X
has to be multiplexed.

As an implementation point: I see you've implemented this with
ifdefs. I think that if we're going to do it we should do it
always, because it's always the case that there are guest signals
that we can't directly represent with host signals, because of
the host libc stealing a couple for its internal use, so we always
need to multiplex at least a few signals. It also makes it easier
to reason about and test if everything is using the same code paths.

thanks
-- PMM