Date: Wed, 14 Jul 2004 20:01:25 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <200407142001.25615.dfr@nlsystems.com> In-Reply-To: <Pine.NEB.3.96L.1040714145151.56002C-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040714145151.56002C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407142001.25615.dfr>