From owner-freebsd-net Thu Mar 8 7:38:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id 8547337B719 for ; Thu, 8 Mar 2001 07:38:18 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 25296BC06D; Thu, 8 Mar 2001 10:38:17 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010307220605.Q41963@prism.flugsvamp.com> "from Jonathan Lemon at Mar 7, 2001 10:06:05 pm" To: Jonathan Lemon Date: Thu, 8 Mar 2001 10:38:17 -0500 (EST) Cc: itojun@iijlab.net, Wietse Venema , Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308153817.25296BC06D@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If the result of connect() write() close() depends on whether accept() happens after or before close(), then the behavior is broken. The client has received a successful return from write() and close(). The system is not supposed to lose the data, period. This race condition did not exist with UNIX-domain sockets on FreeBSD <= 4.2-RELEASE. It was introduced recently. If such behavior is required by standards (i.e. write() and close() succeed, but data is lost because accept() after close() fails) then those standards are badly, badly, broken. Wietse Jonathan Lemon: > On Thu, Mar 08, 2001 at 12:52:31PM +0900, itojun@iijlab.net wrote: > > > > >Several parts of Postfix do: connect() write() close(), where the > > >close() may happen before the server has accept()ed the connection. > > >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes > > >accept() after close() to fail. The already written data is lost. > > >This is a bad incompatible change. > > > > see SUSv2 and XNET 5.2 spec for accept(), and Stevens (unix network > > programming vol 1 2nd ed) section 5.11. > > http://www.opengroup.org/onlinepubs/007908799/xns/accept.html > > > > 4.3BSD behavior was very wrong (described in Stevens). > > > > old freebsd behavior (return 0-length sockaddr) was also wrong, > > it kills a set of applications including sendmail and BIND910. > > > > new freebsd behavior (ECONNABORTED) is at least SUSv2 conformant, > > and I expect it to be the behavior of other stacks. > > > The crucial part of Wietse's message (which he didn't mention in > the first email) is that he's using this setup on unix-domain sockets. > These probably have semantics which are slightly different. > > I believe the correct thing to do at this point is push the > IS_DISCONNECTED test down to each protocol's accept routine, > instead of short-circuiting it in soaccept. It looks like the > short-circuit test was added in uipc_socket.c:1.41 in the NetBSD > sources, which we brought over. I'm not sure why this test is > actually needed, though. > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message