From owner-freebsd-current Sat Dec 12 17:38:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24313 for freebsd-current-outgoing; Sat, 12 Dec 1998 17:38:35 -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 RAA24308 for ; Sat, 12 Dec 1998 17:38:32 -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 RAA27546; Sat, 12 Dec 1998 17:38:19 -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 RAA01794; Sat, 12 Dec 1998 17:38:18 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA22963; Sat, 12 Dec 1998 17:38:16 -0800 (PST) From: Don Lewis Message-Id: <199812130138.RAA22963@salsa.gv.tsc.tdk.com> Date: Sat, 12 Dec 1998 17:38:16 -0800 In-Reply-To: Matthew Dillon "Re: inetd: realloc/free bug" (Dec 11, 4:31pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Matthew Dillon , Peter Edwards Subject: Re: inetd: realloc/free bug Cc: Archie Cobbs , freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Dec 11, 4:31pm, Matthew Dillon wrote: } Subject: Re: inetd: realloc/free bug } I've commited my fix to inetd. As I said before, there } really isn't much to it. You simply allow signal operation } around the select() code and block signals at all other } times and you are done. No fancy pipes, no fancy global } flags, insignificantly delayed signal operation (and } nominally not delayed at all), inherent event serialization, } etc etc etc. 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. 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 for one of the signal handlers to be active when another one is invoked. This is fixable by blocking the other signals from within the handlers, at the expense of more syscalls. I hadn't thought of writing the signals to a pipe and in the past I've always used global flags. I think the pipe idea is kind of elegant because it avoids having to fiddle with the signal masks to avoid race conditions between testing and clearing the flags. 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 the parent and child processes. This fix would roughly translate as the following (ignoring error checking): int pipefd[2]; char c; ctrl = accept(...); pipe(pipefd); pid = fork(); if (pid == 0) { close(pipefd[1]); /* close the write end */ /* wait for EOF */ while (read(pipefd[0], &c, 1) == -1 && errno == EINTR) ; /* nothing */ close(pipefd[0]); fiddle with fds exec(...); } close(pipefd[0]); /* close the read end */ close(ctrl); close(pipefd[1]); /* close the write end to release the child */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message