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

[Richard Henderson <richard.henderson@linaro.org>]

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