cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h

Robert Watson rwatson at
Wed Jul 14 11:56:25 PDT 2004

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 at      Principal Research Scientist, McAfee Research

More information about the cvs-src mailing list