From owner-cvs-all@FreeBSD.ORG Wed Jul 14 18:56:25 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 620A616A4CE; Wed, 14 Jul 2004 18:56:25 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC57543D46; Wed, 14 Jul 2004 18:56:24 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6EIu7Qn058818; Wed, 14 Jul 2004 14:56:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6EIu7vI058815; Wed, 14 Jul 2004 14:56:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jul 2004 14:56:07 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20040714184445.GC95729@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@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 18:56:25 -0000 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. > As far as the locking, we can address that when locking for kqueues are > done, with the idea that SIGIO _should_ work for kqueues. > > Do we have this on the plate? Or are you stalling my work based simply > on wishful thinking? :) There are two outstanding patch sets that add locking to kqueue: - Brian Feldman's "kqgiant" changes, which I'm in the process of updating in Perforce and adapting for your recent additions of fs kqueue events. - John-Mark Gurney's "data locking kqueue" changes, which he's currently working on extracting from his employer. In order for network stack locking without Giant to be real for 5.3, kqueue locking must be completed. The pgsigio do represent a serious obstacle to getting that locking done, both by virtue of adding an immediate coding obstacle to adapt around, but also by introducing an architectural construct that will be difficult to deal with cleanly. My goal is for us to have basic locking for kqueues in the sys tree in CVS within two weeks, using one or another of the two sets of changes above. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research