| Message ID | 20240212205022.242968-2-iii@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | linux-user: Map low priority rt signals | expand |
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; > } >
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; }
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(-)