libc_r kqueue fd leak

[John-Mark Gurney]

Ed Maste wrote this message on Tue, May 24, 2005 at 17:51 -0400:
> On Tue, May 24, 2005 at 01:36:48PM -0400, Ed Maste wrote:
> 
> > On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote:
> > 
> > > We discovered a kqueue leak when running one of our 4.x applications on
> > > FreeBSD 5.3 using the compat libc_r.  It turns out it's caused by libc_r's
> > > close() failing.
> > 
> > I've attached a patch which stops libc_r close() from bailing if fstat()
> > returns an error.  This fixes the kqueue leak.  This logic would also have
> > to make its way into the compat library via 4.x to fully resolve the issue.
> 
> After a little more research it seems the kernel fix is already documented
> in threads/75795.  Version 1.77 of kern_event.c changed kqueue_stat to just
> return ENXIO.
> 
> We discovered the problem because each call in our app to getipnodebyname
> (and in turn the resolver) leaked one kqueue, which eventually used up all
> kernel memory and then caused a panic.
> 
> I noticed that jmg originally did the kqueue locking work which removed
> kqueue_stat, hence the CC:.

yes, the reason I made _stat return ENXIO is that _read and _write are
not supported by kqueue, and so _stat provided useless information.
When I added locking, it would only be reading a value that would
immediately be able to be changed, making it informational at best..
You'd better spend your syscall calling kevent and getting a few
events off the queue than trying to figure out how much work you
have to do...  (In one of my programs, I have code that dynamicly
increases the number of kevent structs I pull off if I get the max..)

After being pestered by ps, I have created a patch.. after a quick test
that it compiles and runs, I'll commit it...  Though libc_r depending
upon _stat seems broken to me...  Who knows what else doesn't implement
_stat and can't be closed..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."