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
--Yylu36WmvOXNoKYn
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from lacrosse.corp.redhat.com (root@lacrosse.corp.redhat.com [207.175.42.154])
by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id TAA20043;
Tue, 6 Jun 2000 19:15:32 -0400
Received: from mail.redhat.com (mail.redhat.com [199.183.24.239])
by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id TAA00445;
Tue, 6 Jun 2000 19:15:32 -0400
Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA20878;
Tue, 6 Jun 2000 19:15:31 -0400
Received: by vger.rutgers.edu via listexpand id <S156865AbQFFWEa>;
Tue, 6 Jun 2000 18:04:30 -0400
Received: by vger.rutgers.edu id <S156790AbQFFVME>;
Tue, 6 Jun 2000 17:12:04 -0400
Received: from naughty.monkey.org ([63.77.239.20]:18159 "HELO
naughty.monkey.org") by vger.rutgers.edu with SMTP
id <S156813AbQFFUQv>; Tue, 6 Jun 2000 16:16:51 -0400
Received: by naughty.monkey.org (Postfix, from userid 1035)
id D131A1086CD; Tue, 6 Jun 2000 16:22:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
by naughty.monkey.org (Postfix) with ESMTP id CBA9F10773E
for <linux-kernel@vger.rutgers.edu>; Tue, 6 Jun 2000 16:22:59 -0400 (EDT)
Date: Tue, 6 Jun 2000 16:22:59 -0400 (EDT)
From: Chuck Lever <cel@monkey.org>
To: linux-kernel@vger.rutgers.edu
Subject: POSIX signal queue overflow bug
Message-ID: <Pine.BSO.4.20.0006061611230.25809-100000@naughty.monkey.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig
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/
--Yylu36WmvOXNoKYn--
- 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/