From owner-cvs-all@FreeBSD.ORG Wed Jul 14 19:01:31 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6AB816A4CE; Wed, 14 Jul 2004 19:01:31 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DEE443D45; Wed, 14 Jul 2004 19:01:28 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i6EJ1Phe001169; Wed, 14 Jul 2004 20:01:25 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Robert Watson Date: Wed, 14 Jul 2004 20:01:25 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407142001.25615.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: cvs-src@FreeBSD.org cc: Alfred Perlstein cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 19:01:31 -0000 On Wednesday 14 July 2004 19:56, Robert Watson wrote: > On Wed, 14 Jul 2004, Alfred Perlstein wrote: > > I'm sure that was a fun panic to hit. :) > > Thrilling :-). Actually, I didn't hit the panic, I merely reasoned > that it might exist and then read more kqueue code than I've read in > a while > > :-). > : > > I can fix this by setting a "sigio in progress" on the kqeue and > > not calling pgsigio() while one is in progress. > > My worry is the inter-subsystem calling. We often call KNOTE() while > holding existing locks in the calling subsystem that we can't drop. > Generally, kqueue is a leaf node subsystem in that it's called from > many places under many circumstances, and needs to not disrupt the > calling state by doing "weird things". What's there before your > change is not too disruptive/weird; afterwards, we call into the body > of the process signalling code which requires additional process > locks. Note that there are other paths to the same suffering: if any > other signal is delivered to a process that's monitoring for signals > with kqueue causing a sigio, you're still recursing into the signal > subsystem. Seems to me that the best thing to do is to defer the psigio() to a taskqueue that will run in a simpler locking environment.