From owner-cvs-all@FreeBSD.ORG Wed Jul 14 19:11:20 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 CD31B16A4CE; Wed, 14 Jul 2004 19:11:20 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CC143D41; Wed, 14 Jul 2004 19:11:18 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AFBCB5C8D6; Wed, 14 Jul 2004 12:11:18 -0700 (PDT) Date: Wed, 14 Jul 2004 12:11:18 -0700 From: Alfred Perlstein To: Doug Rabson Message-ID: <20040714191118.GF95729@elvis.mu.org> References: <200407142001.25615.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407142001.25615.dfr@nlsystems.com> User-Agent: Mutt/1.4.2.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Robert Watson 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 19:11:20 -0000 * Doug Rabson [040714 12:01] wrote: > 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. I was thinking that, but I'm worried about "stale delivery", perhaps we need to record the generation count (process start time) in the sigio as well as the request sent, so that we don't send a signal to the wrong process. ? -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684