Date: Wed, 14 Jul 2004 14:56:07 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <Pine.NEB.3.96L.1040714145151.56002C-100000@fledge.watson.org> In-Reply-To: <20040714184445.GC95729@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040714145151.56002C-100000>