From: Taylor Simpson <tsimpson@quicinc.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Matus Kysel <mkysel@tachyum.com>
Cc: Riku Voipio <riku.voipio@iki.fi>,
"open list:All patches CC here" <qemu-devel@nongnu.org>,
Laurent Vivier <laurent@vivier.eu>
Subject: RE: [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid
Date: Tue, 28 Jan 2020 12:32:55 +0000 [thread overview]
Message-ID: <BYAPR02MB4886C0D683ABE475CBC1F23BDE0A0@BYAPR02MB4886.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CAFEAcA_pOAX=pCk0TfbwwUPHUX2YhLtxMonYVazMrGZBvPJkPw@mail.gmail.com>
I proposed a similar patch guarded by #ifdef TARGET_HEXAGON. I understand we don't want to break things that are working, and we don't want to open the door for a bunch of #ifdef's here. However, more than one scenario needs this capability.
Would a suitable compromise be to provide a hook in linux-user/signal.c for the target to put in the changes they need?
diff --git a/linux-user/hexagon/target_signal.h b/linux-user/hexagon/target_signal.h
index ae52ff5..f82f8c1 100644
--- a/linux-user/hexagon/target_signal.h
+++ b/linux-user/hexagon/target_signal.h
@@ -31,4 +31,15 @@ typedef struct target_sigaltstack {
#include "../generic/signal.h"
+ /*
+ * Hexagon uses the same signal for pthread cancel as the host pthreads,
+ * so cannot be overridden.
+ * Therefore, we map Hexagon signal to a different host signal.
+ */
+#define SIGNAL_MODS \
+ [__SIGRTMIN + 1] = __SIGRTMAX - 1, \
+ [__SIGRTMAX - 1] = __SIGRTMIN + 1,
+
+
+
#endif /* TARGET_SIGNAL_H */
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 5ca6d62..ebca770 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -24,6 +24,7 @@
#include "qemu.h"
#include "trace.h"
#include "signal-common.h"
+#include "target_signal.h"
static struct target_sigaction sigact_table[TARGET_NSIG];
@@ -72,6 +73,9 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
over a single host signal. */
[__SIGRTMIN] = __SIGRTMAX,
[__SIGRTMAX] = __SIGRTMIN,
+#ifdef SIGNAL_MODS
+ SIGNAL_MODS
+#endif
};
static uint8_t target_to_host_signal_table[_NSIG];
Taylor
> -----Original Message-----
> From: Qemu-devel <qemu-devel-
> bounces+tsimpson=quicinc.com@nongnu.org> On Behalf Of Peter Maydell
> Sent: Tuesday, January 28, 2020 3:27 AM
> To: Matus Kysel <mkysel@tachyum.com>
> Cc: Riku Voipio <riku.voipio@iki.fi>; open list:All patches CC here <qemu-
> devel@nongnu.org>; Laurent Vivier <laurent@vivier.eu>
> Subject: Re: [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid
>
> -------------------------------------------------------------------------
> CAUTION: This email originated from outside of the organization.
> -------------------------------------------------------------------------
>
> On Thu, 16 Jan 2020 at 11:58, Matus Kysel <mkysel@tachyum.com> wrote:
> >
> > Used same style to handle another glibc reserved signal SIGSETXID
> > (33), that is used by glibc NPTL setuid/setgid functions. This should
> > fix problems with application using those functions and failing with
> > error "qemu:handle_cpu_signal received signal outside vCPU context".
> >
> > Signed-off-by: Matus Kysel <mkysel@tachyum.com>
> > ---
> > linux-user/signal.c | 13 +++++++++----
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/linux-user/signal.c b/linux-user/signal.c index
> > 0128bde4d2..c59221fd0a 100644
> > --- a/linux-user/signal.c
> > +++ b/linux-user/signal.c
> > @@ -66,11 +66,16 @@ static uint8_t host_to_target_signal_table[_NSIG] =
> {
> > [SIGPWR] = TARGET_SIGPWR,
> > [SIGSYS] = TARGET_SIGSYS,
> > /* next signals stay the same */
> > - /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
> > - host libpthread signals. This assumes no one actually uses SIGRTMAX :-
> /
> > - To fix this properly we need to do manual signal delivery multiplexed
> > - over a single host signal. */
> > + /*
> > + * Nasty hack: Swap SIGRTMIN and SIGRTMIN + 1 with SIGRTMAX and
> SIGRTMAX - 1
> > + * to avoid overlap with host libpthread (NPTL glibc) signals.
> > + * This assumes no one actually uses SIGRTMAX and SIGRTMAX - 1 :-/
> > + * To fix this properly we need to do manual signal delivery multiplexed
> > + * over a single host signal.
> > + */
> > [__SIGRTMIN] = __SIGRTMAX,
> > + [__SIGRTMIN + 1] = __SIGRTMAX - 1,
> > + [__SIGRTMAX - 1] = __SIGRTMIN + 1,
> > [__SIGRTMAX] = __SIGRTMIN,
> > };
> > static uint8_t target_to_host_signal_table[_NSIG];
> > --
> > 2.17.1
>
> This is a long-standing known problem, but doing this is likely to break
> currently-working guest binaries (notably things written in Go). See for
> example the discussion on this thread:
> https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg03804.html
>
> thanks
> -- PMM
next prev parent reply other threads:[~2020-01-28 12:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 11:57 [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid Matus Kysel
2020-01-28 9:22 ` Matus Kysel
2020-01-28 9:26 ` Peter Maydell
2020-01-28 12:32 ` Taylor Simpson [this message]
2020-01-28 12:45 ` Peter Maydell
2020-01-28 14:41 ` Laurent Vivier
2020-01-29 16:12 ` Laurent Vivier
2020-01-30 10:25 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BYAPR02MB4886C0D683ABE475CBC1F23BDE0A0@BYAPR02MB4886.namprd02.prod.outlook.com \
--to=tsimpson@quicinc.com \
--cc=laurent@vivier.eu \
--cc=mkysel@tachyum.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).