cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h
dfr at nlsystems.com
Wed Jul 14 12:01:31 PDT 2004
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
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.
More information about the cvs-src