Re: esd leaking file descriptors

On Mon, 7 Jun 2004, Brian Feldman wrote:

> > I just tried a kernel from June, 1st: esd doesn't leak any file
> > descriptors. So it's definitely a CURRENT problem.
> > 
> > I couldn't spot anything suspicous using ktrace (That is no notable
> > difference compared to the other machine).
> > 
> > Here are two excerpts from kdump output that basically repeat all the
> > time:
> 
> I see a lot of accept(2) there... I think it's a good possibility Robert
> accidentally broke accept[1]()'s error cleanup.  It seems that the file
> is dropped but the fd is left sitting around in a half-allocated state. 
> Many of those 'goto done;'s should be 'goto noconnection;'s, I believe. 

That's what I was wondering -- it looks like the 'goto done's following
falloc()'s failure check should be "goto noconnection".  Here's a patch
that cleans that up, but may not be perfect.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research


Index: uipc_syscalls.c
===================================================================
RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.187
diff -u -r1.187 uipc_syscalls.c
--- uipc_syscalls.c	7 Jun 2004 09:59:50 -0000	1.187
+++ uipc_syscalls.c	7 Jun 2004 19:38:39 -0000
_at__at_ -285,7 +285,7 _at__at_
 	if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) {
 		ACCEPT_UNLOCK();
 		error = EWOULDBLOCK;
-		goto done;
+		goto noconnection;
 	}
 	while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) {
 		if (head->so_state & SS_CANTRCVMORE) {
_at__at_ -296,14 +296,14 _at__at_
 		    "accept", 0);
 		if (error) {
 			ACCEPT_UNLOCK();
-			goto done;
+			goto noconnection;
 		}
 	}
 	if (head->so_error) {
 		error = head->so_error;
 		head->so_error = 0;
 		ACCEPT_UNLOCK();
-		goto done;
+		goto noconnection;
 	}
 	so = TAILQ_FIRST(&head->so_comp);
 	KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP"));