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

[Ilya Leoshkevich <iii@linux.ibm.com>]

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?