[PATCH v2 0/2] linux-user: Map low priority rt signals

[PATCH v2 0/2] linux-user: Map low priority rt signals

[Ilya Leoshkevich]

Hi,

There are apps out there that want to use SIGRTMAX, which linux-user
currently does not map to a host signal. The reason is that with the
current approach it's not possible to map all target signals, so it
was decided to sacrifice the end of the range.

In this series I propose to sacrifice the middle instead. Patch 1 makes
the change, patch 2 is a test.

Best regards,
Ilya

Ilya Leoshkevich (2):
  linux-user: Map low priority rt signals
  tests/tcg: Add SIGRTMIN/SIGRTMAX test

 linux-user/signal.c                           | 18 +++++---
 tests/tcg/multiarch/linux/linux-sigrtminmax.c | 41 +++++++++++++++++++
 2 files changed, 54 insertions(+), 5 deletions(-)
 create mode 100644 tests/tcg/multiarch/linux/linux-sigrtminmax.c

-- 
2.43.0

[PATCH v2 1/2] linux-user: Map low priority rt signals

[Ilya Leoshkevich]

Some applications want to use low priority realtime signals (e.g.,
SIGRTMAX). Currently QEMU cannot map all target realtime signals to
host signals, and chooses to sacrifice the end of the target realtime
signal range.

Change this to the middle of that range, hoping that fewer applications
will need it.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
 linux-user/signal.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index d3e62ab030f..a81533b563a 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -511,13 +511,14 @@ static int core_dump_signal(int sig)
 
 static void signal_table_init(void)
 {
-    int hsig, tsig, count;
+    int hsig, hsig_count, tsig, tsig_count, tsig_hole, tsig_hole_size, count;
 
     /*
-     * Signals are supported starting from TARGET_SIGRTMIN and going up
-     * until we run out of host realtime signals.  Glibc uses the lower 2
-     * RT signals and (hopefully) nobody uses the upper ones.
-     * This is why SIGRTMIN (34) is generally greater than __SIGRTMIN (32).
+     * Signals are supported starting from TARGET_SIGRTMIN and up to
+     * TARGET_SIGRTMAX, potentially with a hole in the middle of this
+     * range, which, hopefully, nobody uses. Glibc uses the lower 2 RT
+     * signals; this is why SIGRTMIN (34) is generally greater than
+     * __SIGRTMIN (32).
      * To fix this properly we would need to do manual signal delivery
      * multiplexed over a single host signal.
      * Attempts for configure "missing" signals via sigaction will be
@@ -536,9 +537,16 @@ static void signal_table_init(void)
     host_to_target_signal_table[SIGABRT] = 0;
     host_to_target_signal_table[hsig++] = TARGET_SIGABRT;
 
+    hsig_count = SIGRTMAX - hsig + 1;
+    tsig_count = TARGET_NSIG - TARGET_SIGRTMIN + 1;
+    tsig_hole_size = tsig_count - MIN(hsig_count, tsig_count);
+    tsig_hole = TARGET_SIGRTMIN + (tsig_count - tsig_hole_size) / 2;
     for (tsig = TARGET_SIGRTMIN;
          hsig <= SIGRTMAX && tsig <= TARGET_NSIG;
          hsig++, tsig++) {
+        if (tsig == tsig_hole) {
+            tsig += tsig_hole_size;
+        }
         host_to_target_signal_table[hsig] = tsig;
     }
 
-- 
2.43.0

Re: [PATCH v2 1/2] linux-user: Map low priority rt signals

[Philippe Mathieu-Daudé]

Cc'ing Brian & Taylor

On 12/2/24 21:45, Ilya Leoshkevich wrote:
> Some applications want to use low priority realtime signals (e.g.,
> SIGRTMAX). Currently QEMU cannot map all target realtime signals to
> host signals, and chooses to sacrifice the end of the target realtime
> signal range.
> 
> Change this to the middle of that range, hoping that fewer applications
> will need it.
> 
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
>   linux-user/signal.c | 18 +++++++++++++-----
>   1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index d3e62ab030f..a81533b563a 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -511,13 +511,14 @@ static int core_dump_signal(int sig)
>   
>   static void signal_table_init(void)
>   {
> -    int hsig, tsig, count;
> +    int hsig, hsig_count, tsig, tsig_count, tsig_hole, tsig_hole_size, count;
>   
>       /*
> -     * Signals are supported starting from TARGET_SIGRTMIN and going up
> -     * until we run out of host realtime signals.  Glibc uses the lower 2
> -     * RT signals and (hopefully) nobody uses the upper ones.
> -     * This is why SIGRTMIN (34) is generally greater than __SIGRTMIN (32).
> +     * Signals are supported starting from TARGET_SIGRTMIN and up to
> +     * TARGET_SIGRTMAX, potentially with a hole in the middle of this
> +     * range, which, hopefully, nobody uses. Glibc uses the lower 2 RT
> +     * signals; this is why SIGRTMIN (34) is generally greater than
> +     * __SIGRTMIN (32).
>        * To fix this properly we would need to do manual signal delivery
>        * multiplexed over a single host signal.
>        * Attempts for configure "missing" signals via sigaction will be
> @@ -536,9 +537,16 @@ static void signal_table_init(void)
>       host_to_target_signal_table[SIGABRT] = 0;
>       host_to_target_signal_table[hsig++] = TARGET_SIGABRT;
>   
> +    hsig_count = SIGRTMAX - hsig + 1;
> +    tsig_count = TARGET_NSIG - TARGET_SIGRTMIN + 1;
> +    tsig_hole_size = tsig_count - MIN(hsig_count, tsig_count);
> +    tsig_hole = TARGET_SIGRTMIN + (tsig_count - tsig_hole_size) / 2;
>       for (tsig = TARGET_SIGRTMIN;
>            hsig <= SIGRTMAX && tsig <= TARGET_NSIG;
>            hsig++, tsig++) {
> +        if (tsig == tsig_hole) {
> +            tsig += tsig_hole_size;
> +        }
>           host_to_target_signal_table[hsig] = tsig;
>       }
>   

Ping: [PATCH v2 1/2] linux-user: Map low priority rt signals

[Ilya Leoshkevich]

On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
> Cc'ing Brian & Taylor
> 
> On 12/2/24 21:45, Ilya Leoshkevich wrote:
> > Some applications want to use low priority realtime signals (e.g.,
> > SIGRTMAX). Currently QEMU cannot map all target realtime signals to
> > host signals, and chooses to sacrifice the end of the target
> > realtime
> > signal range.
> > 
> > Change this to the middle of that range, hoping that fewer
> > applications
> > will need it.
> > 
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> >   linux-user/signal.c | 18 +++++++++++++-----
> >   1 file changed, 13 insertions(+), 5 deletions(-)
> > 
> > diff --git a/linux-user/signal.c b/linux-user/signal.c
> > index d3e62ab030f..a81533b563a 100644
> > --- a/linux-user/signal.c
> > +++ b/linux-user/signal.c
> > @@ -511,13 +511,14 @@ static int core_dump_signal(int sig)
> >   
> >   static void signal_table_init(void)
> >   {
> > -    int hsig, tsig, count;
> > +    int hsig, hsig_count, tsig, tsig_count, tsig_hole,
> > tsig_hole_size, count;
> >   
> >       /*
> > -     * Signals are supported starting from TARGET_SIGRTMIN and
> > going up
> > -     * until we run out of host realtime signals.  Glibc uses the
> > lower 2
> > -     * RT signals and (hopefully) nobody uses the upper ones.
> > -     * This is why SIGRTMIN (34) is generally greater than
> > __SIGRTMIN (32).
> > +     * Signals are supported starting from TARGET_SIGRTMIN and up
> > to
> > +     * TARGET_SIGRTMAX, potentially with a hole in the middle of
> > this
> > +     * range, which, hopefully, nobody uses. Glibc uses the lower
> > 2 RT
> > +     * signals; this is why SIGRTMIN (34) is generally greater
> > than
> > +     * __SIGRTMIN (32).
> >        * To fix this properly we would need to do manual signal
> > delivery
> >        * multiplexed over a single host signal.
> >        * Attempts for configure "missing" signals via sigaction
> > will be
> > @@ -536,9 +537,16 @@ static void signal_table_init(void)
> >       host_to_target_signal_table[SIGABRT] = 0;
> >       host_to_target_signal_table[hsig++] = TARGET_SIGABRT;
> >   
> > +    hsig_count = SIGRTMAX - hsig + 1;
> > +    tsig_count = TARGET_NSIG - TARGET_SIGRTMIN + 1;
> > +    tsig_hole_size = tsig_count - MIN(hsig_count, tsig_count);
> > +    tsig_hole = TARGET_SIGRTMIN + (tsig_count - tsig_hole_size) /
> > 2;
> >       for (tsig = TARGET_SIGRTMIN;
> >            hsig <= SIGRTMAX && tsig <= TARGET_NSIG;
> >            hsig++, tsig++) {
> > +        if (tsig == tsig_hole) {
> > +            tsig += tsig_hole_size;
> > +        }
> >           host_to_target_signal_table[hsig] = tsig;
> >       }
> >   

Ping.

I wonder if it would make sense to make this configurable?

Re: Ping: [PATCH v2 1/2] linux-user: Map low priority rt signals

[Richard Henderson]

On 10/25/24 10:32, Ilya Leoshkevich wrote:
> On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
>> Cc'ing Brian & Taylor
>>
>> On 12/2/24 21:45, Ilya Leoshkevich wrote:
>>> Some applications want to use low priority realtime signals (e.g.,
>>> SIGRTMAX). Currently QEMU cannot map all target realtime signals to
>>> host signals, and chooses to sacrifice the end of the target
>>> realtime
>>> signal range.
>>>
>>> Change this to the middle of that range, hoping that fewer
>>> applications
>>> will need it.
>>>
>>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>>> ---
>>>    linux-user/signal.c | 18 +++++++++++++-----
>>>    1 file changed, 13 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/linux-user/signal.c b/linux-user/signal.c
>>> index d3e62ab030f..a81533b563a 100644
>>> --- a/linux-user/signal.c
>>> +++ b/linux-user/signal.c
>>> @@ -511,13 +511,14 @@ static int core_dump_signal(int sig)
>>>    
>>>    static void signal_table_init(void)
>>>    {
>>> -    int hsig, tsig, count;
>>> +    int hsig, hsig_count, tsig, tsig_count, tsig_hole,
>>> tsig_hole_size, count;
>>>    
>>>        /*
>>> -     * Signals are supported starting from TARGET_SIGRTMIN and
>>> going up
>>> -     * until we run out of host realtime signals.  Glibc uses the
>>> lower 2
>>> -     * RT signals and (hopefully) nobody uses the upper ones.
>>> -     * This is why SIGRTMIN (34) is generally greater than
>>> __SIGRTMIN (32).
>>> +     * Signals are supported starting from TARGET_SIGRTMIN and up
>>> to
>>> +     * TARGET_SIGRTMAX, potentially with a hole in the middle of
>>> this
>>> +     * range, which, hopefully, nobody uses. Glibc uses the lower
>>> 2 RT
>>> +     * signals; this is why SIGRTMIN (34) is generally greater
>>> than
>>> +     * __SIGRTMIN (32).
>>>         * To fix this properly we would need to do manual signal
>>> delivery
>>>         * multiplexed over a single host signal.
>>>         * Attempts for configure "missing" signals via sigaction
>>> will be
>>> @@ -536,9 +537,16 @@ static void signal_table_init(void)
>>>        host_to_target_signal_table[SIGABRT] = 0;
>>>        host_to_target_signal_table[hsig++] = TARGET_SIGABRT;
>>>    
>>> +    hsig_count = SIGRTMAX - hsig + 1;
>>> +    tsig_count = TARGET_NSIG - TARGET_SIGRTMIN + 1;
>>> +    tsig_hole_size = tsig_count - MIN(hsig_count, tsig_count);
>>> +    tsig_hole = TARGET_SIGRTMIN + (tsig_count - tsig_hole_size) /
>>> 2;
>>>        for (tsig = TARGET_SIGRTMIN;
>>>             hsig <= SIGRTMAX && tsig <= TARGET_NSIG;
>>>             hsig++, tsig++) {
>>> +        if (tsig == tsig_hole) {
>>> +            tsig += tsig_hole_size;
>>> +        }
>>>            host_to_target_signal_table[hsig] = tsig;
>>>        }
>>>    
> 
> Ping.
> 
> I wonder if it would make sense to make this configurable?

There are plenty of IPC use-cases for which we need a consistent mapping of guest signals. 
  Because we must steal some for emulation, we cannot give the guest the full set.  But 
you're right that different applications allocate the rt signals differently, and 
arbitrarily nixing the highest signal numbers may be problematic.

Nixing the middle rt signals seems equally problematic, so some sort of configuration 
seems the only solution.  Perhaps we could come up with some generalized mapping?


r~


  perhaps a generalized mapping

Re: Ping: [PATCH v2 1/2] linux-user: Map low priority rt signals

[Ilya Leoshkevich]

On Fri, 2024-10-25 at 16:36 +0100, Richard Henderson wrote:
> On 10/25/24 10:32, Ilya Leoshkevich wrote:
> > On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
> > > Cc'ing Brian & Taylor
> > > 
> > > On 12/2/24 21:45, Ilya Leoshkevich wrote:
> > > > Some applications want to use low priority realtime signals
> > > > (e.g.,
> > > > SIGRTMAX). Currently QEMU cannot map all target realtime
> > > > signals to
> > > > host signals, and chooses to sacrifice the end of the target
> > > > realtime
> > > > signal range.
> > > > 
> > > > Change this to the middle of that range, hoping that fewer
> > > > applications
> > > > will need it.
> > > > 
> > > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > > > ---
> > > >    linux-user/signal.c | 18 +++++++++++++-----
> > > >    1 file changed, 13 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/linux-user/signal.c b/linux-user/signal.c
> > > > index d3e62ab030f..a81533b563a 100644
> > > > --- a/linux-user/signal.c
> > > > +++ b/linux-user/signal.c
> > > > @@ -511,13 +511,14 @@ static int core_dump_signal(int sig)
> > > >    
> > > >    static void signal_table_init(void)
> > > >    {
> > > > -    int hsig, tsig, count;
> > > > +    int hsig, hsig_count, tsig, tsig_count, tsig_hole,
> > > > tsig_hole_size, count;
> > > >    
> > > >        /*
> > > > -     * Signals are supported starting from TARGET_SIGRTMIN and
> > > > going up
> > > > -     * until we run out of host realtime signals.  Glibc uses
> > > > the
> > > > lower 2
> > > > -     * RT signals and (hopefully) nobody uses the upper ones.
> > > > -     * This is why SIGRTMIN (34) is generally greater than
> > > > __SIGRTMIN (32).
> > > > +     * Signals are supported starting from TARGET_SIGRTMIN and
> > > > up
> > > > to
> > > > +     * TARGET_SIGRTMAX, potentially with a hole in the middle
> > > > of
> > > > this
> > > > +     * range, which, hopefully, nobody uses. Glibc uses the
> > > > lower
> > > > 2 RT
> > > > +     * signals; this is why SIGRTMIN (34) is generally greater
> > > > than
> > > > +     * __SIGRTMIN (32).
> > > >         * To fix this properly we would need to do manual
> > > > signal
> > > > delivery
> > > >         * multiplexed over a single host signal.
> > > >         * Attempts for configure "missing" signals via
> > > > sigaction
> > > > will be
> > > > @@ -536,9 +537,16 @@ static void signal_table_init(void)
> > > >        host_to_target_signal_table[SIGABRT] = 0;
> > > >        host_to_target_signal_table[hsig++] = TARGET_SIGABRT;
> > > >    
> > > > +    hsig_count = SIGRTMAX - hsig + 1;
> > > > +    tsig_count = TARGET_NSIG - TARGET_SIGRTMIN + 1;
> > > > +    tsig_hole_size = tsig_count - MIN(hsig_count, tsig_count);
> > > > +    tsig_hole = TARGET_SIGRTMIN + (tsig_count -
> > > > tsig_hole_size) /
> > > > 2;
> > > >        for (tsig = TARGET_SIGRTMIN;
> > > >             hsig <= SIGRTMAX && tsig <= TARGET_NSIG;
> > > >             hsig++, tsig++) {
> > > > +        if (tsig == tsig_hole) {
> > > > +            tsig += tsig_hole_size;
> > > > +        }
> > > >            host_to_target_signal_table[hsig] = tsig;
> > > >        }
> > > >    
> > 
> > Ping.
> > 
> > I wonder if it would make sense to make this configurable?
> 
> There are plenty of IPC use-cases for which we need a consistent
> mapping of guest signals. 
>   Because we must steal some for emulation, we cannot give the guest
> the full set.  But 
> you're right that different applications allocate the rt signals
> differently, and 
> arbitrarily nixing the highest signal numbers may be problematic.
> 
> Nixing the middle rt signals seems equally problematic, so some sort
> of configuration 
> seems the only solution.  Perhaps we could come up with some
> generalized mapping?

Sounds good. I guess we don't need that for non-realtime signals?

Perhaps we could use the same logic as uid_map?

export QEMU_RTSIG_MAP="tsig1 hsig1 n1,tsig2 hsig2 len2"

If specified, [hsig, hsig+n) will be mapped to [tsig, tsig+n), and
qemu-user will exit with an error if either is out of range or there
are no host realtime signals left to steal.

If not specified, today's mapping will be used. I think it may also
make sense to make the default configurable, e.g., with
./configure --default-rtsig-map-ppc64le="tsig1 hsig1 n1"

What do you think?

[PATCH v2 2/2] tests/tcg: Add SIGRTMIN/SIGRTMAX test

[Ilya Leoshkevich]

Test the lowest and the highest real-time signals.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
 tests/tcg/multiarch/linux/linux-sigrtminmax.c | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 tests/tcg/multiarch/linux/linux-sigrtminmax.c

diff --git a/tests/tcg/multiarch/linux/linux-sigrtminmax.c b/tests/tcg/multiarch/linux/linux-sigrtminmax.c
new file mode 100644
index 00000000000..773383a3fef
--- /dev/null
+++ b/tests/tcg/multiarch/linux/linux-sigrtminmax.c
@@ -0,0 +1,41 @@
+/*
+ * Test the lowest and the highest real-time signals.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include <assert.h>
+#include <signal.h>
+#include <stdbool.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+static bool seen_sigrtmin, seen_sigrtmax;
+
+static void handle_signal(int sig)
+{
+    if (sig == SIGRTMIN) {
+        seen_sigrtmin = true;
+    } else if (sig == SIGRTMAX) {
+        seen_sigrtmax = true;
+    } else {
+        _exit(1);
+    }
+}
+
+int main(void)
+{
+    struct sigaction act;
+
+    memset(&act, 0, sizeof(act));
+    act.sa_handler = handle_signal;
+    assert(sigaction(SIGRTMIN, &act, NULL) == 0);
+    assert(sigaction(SIGRTMAX, &act, NULL) == 0);
+
+    assert(kill(getpid(), SIGRTMIN) == 0);
+    assert(seen_sigrtmin);
+    assert(kill(getpid(), SIGRTMAX) == 0);
+    assert(seen_sigrtmax);
+
+    return EXIT_SUCCESS;
+}
-- 
2.43.0