From owner-freebsd-current Sat Dec 12 17:58:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25885 for freebsd-current-outgoing; Sat, 12 Dec 1998 17:58:51 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA25880 for ; Sat, 12 Dec 1998 17:58:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA14315; Sat, 12 Dec 1998 17:58:42 -0800 (PST) (envelope-from dillon) Date: Sat, 12 Dec 1998 17:58:42 -0800 (PST) From: Matthew Dillon Message-Id: <199812130158.RAA14315@apollo.backplane.com> To: Don Lewis Cc: Peter Edwards , Archie Cobbs , freebsd-current@FreeBSD.ORG Subject: Re: inetd: realloc/free bug References: <199812130138.RAA22963@salsa.gv.tsc.tdk.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It also has the downside of keeping inetd "active", so it can't :be totally swapped out if it's not in use. This might be a bit :of a concern to some folks, like those who run FreeBSD on their :laptops. Your implementation is also more syscall intensive than :some of the alternatives. We may be able to remove the timeout from the select(), but someone else is going to have to go through the code (as I indicated earlier) to determine that this is the case before removing the timeout. :Your patch also doesn't eliminate all the race conditions. When :a signal handler is invoked, it blocks reception of the signal that :triggered it, but not the reception of other signals, so it is possible Sure it does. Look at the code. Line 410 or so of inetd.c :Oh yeah, there is another race condition that I've never seen mentioned. :In the case of TCP services where we do something like : ctrl = accept(...); : pid = fork(); : if (pid == 0) { : fiddle with fds : exec(...); : } : close(ctrl); :there is a problem if the child process runs, writes a bunch of data :to the socket and exits before the parent process executes the close(). :If this happens, the close() in the parent can hang for an indefinite :period of time, until the client consumes the buffered data on the socket. :I fixed this in BIND 4.x a few years ago using a pipe to synchronize I'm not sure I follow. close() on a socket descriptor does not block. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message