Re: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1

[Josh Kunz <jkz@google.com>]

[-- Attachment #1: Type: text/plain, Size: 8280 bytes --]

So, this turned out to be much more complicated than I initially expected.

The current linux-user signal-handling implementation makes the assumption
that there is a 1:1 correspondence between host signals, and target (guest)
signals in a whole bunch of places. Breaking this assumption breaks a lot
of the signal handling code. I’m no longer sure that “multiplexing” is a
good solution. Here are some of the issues I’ve run into while implementing
this patch:

* Signal masks no longer work. The existing signal handling routines assume
that target masks can be translated into equivalent host masks, but if
multiple target signals map to a single host signal, the masks are no
longer equivalent. This can be addressed by maintaining a separate emulated
target signal mask (which is checked in process_pending_signals). Note:
this is largely addressed by Milos/Aleksandar's patch.
* sigaction no longer works. Right now, even though SIGRTMIN is mapped to
SIGRTMAX, we are still allowed to do a “sigaction” on the signal. Without a
1:1 mapping, the action table must be fully emulated.
* Syscall interruption (SA_RESTART and EINTR) breaks. Emulating the signal
action table means that QEMU must now implement SA_RESTART behavior (we
can’t rely on the kernel to do this), which will require changes to most
syscalls.
* sigsuspend breaks. To avoid masking too many signals with a sigsuspend,
the host mask used for “sigsuspend” cannot block the multiplexing signal.
This means that the sigsuspend handler may get interrupted by a multiplexed
signal that is supposed to be masked by the target. Linux user-mode will
have to support signal queueing to track pending RT signals.
* signalfd breaks. If the user includes a multiplexed signal in the
“signalfd” set, then signalfd behavior will have to be fully emulated. The
only way I can think to support this is by either completely emulating FDs,
or by using something like “eventfd” or “memfd” to make a fake signalfd
(that still works with select), and then injecting siginfo structures when
the fake FD is read. Not pretty.
* sigtimedwait breaks. The given (target) sigset will not have an
equivalent host sigset if some target signals are multiplexed. The host
sigset will either be too large (possibly receiving some signals that
should remain pending), or too small (missing signals that fulfil the
target’s criteria, which is unacceptable). This can be worked-around by
re-queuing signals and using -TARGET_ERESTARTSYS, but it’s quite
complicated to make this appear atomic.

These are just the things I have found so far. I’m not sure if this is
everything that is required to add actual signal multiplexing support.

If QEMU follows through with signal multiplexing, it will be a big change
to QEMU signal handling. Full emulation of these signal aspects will bring
QEMU further away from kernel behavior, and introduce the possibility of
bugs or incompatibilities in QEMU’s signal-handling layer. To support
signals outside the host range, this is unavoidable; but for the SIGRTMIN,
SIGRTMIN+1 case, I’m not sure it’s worth it.

After considering these drawbacks, do the QEMU maintainers still think this
is the right approach for handling these libc reserved signals?

On Fri, Aug 30, 2019 at 6:26 PM Josh Kunz <jkz@google.com> wrote:

> I can take over the series. I'll rebase the patch set, and update it to
> address the SIGRTMIN - 1 issue. I should have an update sometime next week.
>
> On Wed, Aug 28, 2019 at 10:31 AM Aleksandar Markovic <
> amarkovic@wavecomp.com> wrote:
>
>> > From: Laurent Vivier <laurent@vivier.eu>
>> > Sent: Wednesday, August 28, 2019 10:51 AM
>> > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com
>> > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi;
>> > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar
>> Markovic
>> > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and
>> SIGRTMAX - 1
>> >
>> > Le 26/08/2019 à 23:10, Josh Kunz a écrit :
>> > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu
>> > > <mailto:laurent@vivier.eu>> wrote:
>> > >
>> > >     Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit :
>> > >     > Hi all,
>> > >     >
>> > >     > I have also experienced issues with SIGRTMIN + 1, and am
>> interested in
>> > >     > moving this patch forwards. Anything I can do here to help?
>> Would the
>> > >     > maintainers prefer myself or Marli re-submit the patch?
>> > >     >
>> > >     > The Go issue here seems particularly sticky. Even if we update
>> the Go
>> > >     > runtime, users may try and run older binaries built with older
>> > >     versions of
>> > >     > Go for quite some time (months? years?). Would it be better to
>> > >     hide this
>> > >     > behind some kind of build-time flag
>> > >     (`--enable-sigrtmin-plus-one-proxy` or
>> > >     > something), so that some users can opt-in, but older binaries
>> > >     still work as
>> > >     > expected?
>> > >     >
>> > >     > Also, here is a link to the original thread this message is in
>> > >     reply to
>> > >     > in-case my mail-client doesn't set up the reply properly:
>> > >     >
>> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html
>> > >
>> > >     The problem here is we break something to fix something else.
>> > >
>> > >     I'm wondering if the series from Aleksandar Markovic, "linux-user:
>> > >     Support signal passing for targets having more signals than host"
>> [1]
>> > >     can fix the problem in a better way?
>> > >
>> > >
>> > > That patch[1] (which I'll refer to as the MUX patch to avoid
>> confusion)
>> > > does not directly fix the issue addressed by this patch (re-wiring
>> > > SIGRTMIN+1), but since it basically implements generic signal
>> > > multiplexing, it could be re-worked to address this case as well. The
>> > > way it handles `si_code` spooks me a little bit. It could easily be
>> > > broken by a kernel version change, and such a breakage could be hard
>> to
>> > > detect or lead to surprising results. Other than that, it looks like a
>> > > reasonable implementation.
>> > >
>> > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic
>> > > signal-multiplexing mechanism doesn't seem *that* much better to me.
>> It
>> > > adds a lot of complexity, and only saves a single signal (assuming
>> glibc
>> > > doesn't add more reserved signals). The "big win" is additional
>> > > emulation features, like those introduced in MUX patch (being able to
>> > > utilize signals outside of the host range). If having those features
>> in
>> > > QEMU warrants the additional complexity, then re-working this patch
>> > > on-top of that infrastructure seems like a good idea.
>> > >
>> > > If the maintainers want to go down that route, then I would be happy
>> to
>> > > re-work this patch utilizing the infrastructure from the MUX patch.
>> > > Unfortunately it will require non-trivial changes, so it may be best
>> to
>> > > wait until that patch is merged. I could also provide a patch "on top
>> > > of" the MUX patch, if that's desired/more convenient.
>> > >
>> > > Just one last note, if you do decide to merge the MUX patch, then it
>> > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the
>> > > multiplexing signal if possible, to avoid breaking go binaries.
>> > >
>> >
>> > Personally, I prefer a solution that breaks nothing.
>> >
>> > Aleksandar, Milos,
>> >
>> > do you have an updated version of you series "Support signal passing for
>> > targets having more signals than host"?
>> >
>>
>> Milos is unfortunetely working on an entirely different project now, and
>> can't spare enough time to finish the series. I am also busy with other
>> issues, even though I would like very much this or equivalent solution to
>> be integrated. Alternatively, someone in the team may have time later this
>> year, but I do not know that yet  - perhaps somebody else (Josh) can take
>> over the series?
>>
>> Sincerely,
>> Aleksandar
>>
>>
>> > Thanks,
>> > Laurent
>> >
>
>

[-- Attachment #2: Type: text/html, Size: 10077 bytes --]