Subject: Re: problem with Squid losing socket file descriptors (NetBSD-1.3.3)
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 10/23/1999 03:31:57
[ On Saturday, October 23, 1999 at 15:50:53 (+1000), Darren Reed wrote: ]
> Subject: Re: problem with Squid losing socket file descriptors (NetBSD-1.3.3)
> This bug has been fixed and some time ago. The fix is trivial enough
> that you should be able to copy the changes back to 1.3.3 if you don't
> want to upgrade to 1.4.1 or -current.
> I found and fixed the bug without submitting a PR when I was working on
> testing how system calls handled programmed failure conditions.
Do you mean this change from sys/kern/uipc_syscalls.c?
date: 1999/07/01 05:56:32; author: darrenr; state: Exp; lines: +15 -1
fix sys_accept() to return EOPNOTSUPP for protocols which don't support
listen/accept (PR_LISTEN flag in protosw) and detect obvious faults in
parameters passed. It is still possible for the address used for copying
the socket information to become invalid between that check and the copyout
so close the connection's allocated fd if the copyout fails so that we can
return EFAULT without allocating an fd and the application not knowing about
it. Ideally we'd be able to queue the connection back up so a later accept
could retrieve it but unfortunately that's not possible.
... but that change isn't in 1.4.1 (as of Sept. 1, only 1.42 had been
If so I'll try pulling that into my 1.3.3 tree and see if things get
better. If not then please send me a more direct pointer....
Hmmm.... sounds like the manual page needs updating too....
(BTW, the FreeBSD code looks quite a bit different in here, not only
because it was derived from 4.4lite2, and seems a bit more logical too,
at least to me. It does seem to try to put a connection back on the
queue if falloc() fails, though not later when the copyout() fails when
it really is too late ;-)
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>