Hi,
On Tue, Jun 06, 2000 at 04:22:59PM -0400, Chuck Lever wrote:
>
> i've been playing with zab's web server, and discovered that when the
> Posix RT signal queue overflows, no signal is raised. the kernel is
> supposed to raise SIGIO when the queue overflows.
>
> looking at kernel/signal.c, it appears that an overflow signal will only
> happen if si_code is one of the kernel-generated signals. unfortunately
> for applications like zab's server, even though these are
> "kernel-generated" signals, si_code is positive for all the signals it
> queues (POLL_IN, and so on, are all positive).
> here's a suggested patch to 2.4.0-pre that fixes the bug. can anyone see
> a problem with this?
Right. The sigqueue is supposed to fail in this case, not to fall
through to the fallback signal. send_sigio_to_task should detect the
failure and will automatically deliver a non-queued SIGIO instead if
this happens.
The comment states that only kill() should fall through to the unqueued
signal delivery. This looks like the right fix.
Alan, please apply.
Cheers,
Stephen
attached mail follows:
hi all-
i've been playing with zab's web server, and discovered that when the
Posix RT signal queue overflows, no signal is raised. the kernel is
supposed to raise SIGIO when the queue overflows.
looking at kernel/signal.c, it appears that an overflow signal will only
happen if si_code is one of the kernel-generated signals. unfortunately
for applications like zab's server, even though these are
"kernel-generated" signals, si_code is positive for all the signals it
queues (POLL_IN, and so on, are all positive).
here's a suggested patch to 2.4.0-pre that fixes the bug. can anyone see
a problem with this? there is no MAINTAINER listed for this specific area
of the kernel, so i'm posting here.
--- kernel/signal.c.orig Fri May 26 15:46:55 2000
+++ kernel/signal.c Tue Jun 6 16:09:38 2000
@@ -375,7 +375,7 @@
break;
}
} else if (sig >= SIGRTMIN && info && (unsigned long)info != 1
- && info->si_code < 0) {
+ && info->si_code != SI_USER) {
/*
* Queue overflow, abort. We may abort if the signal was rt
* and sent by user using something other than kill().
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@bigfoot.com>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:16 EST