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

[Josh Kunz]

On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <address@hidden> 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.

Thanks again for taking a look at this issue.

Cheers,
Josh Kunz

[1] http://patchwork.ozlabs.org/cover/1103565/