From owner-freebsd-current Sat Dec 12 19:32:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03819 for freebsd-current-outgoing; Sat, 12 Dec 1998 19:32:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03813 for ; Sat, 12 Dec 1998 19:32:18 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id TAA28023; Sat, 12 Dec 1998 19:32:12 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id TAA03457; Sat, 12 Dec 1998 19:32:10 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA23232; Sat, 12 Dec 1998 19:32:09 -0800 (PST) From: Don Lewis Message-Id: <199812130332.TAA23232@salsa.gv.tsc.tdk.com> Date: Sat, 12 Dec 1998 19:32:09 -0800 In-Reply-To: Matthew Dillon "Re: inetd: realloc/free bug" (Dec 12, 5:58pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Matthew Dillon , Don Lewis Subject: Re: inetd: realloc/free bug Cc: Peter Edwards , Archie Cobbs , freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Dec 12, 5:58pm, Matthew Dillon wrote: } Subject: Re: inetd: realloc/free bug } :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 You appear to be correct. } :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. In the case of BIND, close() blocks because SO_LINGER is set. As long as nothing run from inetd does this, we're probably OK. The reason that BIND uses SO_LINGER is: /* kernels that map pages for IO end up failing if the pipe is full * at exit and we take away the final buffer. this is really a kernel * bug but it's harmless on systems that are not broken, so... */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message