Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2005 16:01:31 -0700
From:      John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To:        Ed Maste <emaste@phaedrus.sandvine.ca>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: libc_r kqueue fd leak
Message-ID:  <20050524230131.GN959@funkthat.com>
In-Reply-To: <20050524215153.GA35718@sandvine.com>
References:  <20050524165907.GA20674@sandvine.com> <20050524173648.GA29183@sandvine.com> <20050524215153.GA35718@sandvine.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050524230131.GN959>