| Message ID | 20240212205022.242968-2-iii@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| 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; > } >
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?
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
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?
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(-)