From owner-freebsd-net Tue Aug 13 13:54:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5920737B400 for ; Tue, 13 Aug 2002 13:54:42 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BBE143E65 for ; Tue, 13 Aug 2002 13:54:40 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:8050:201:14:65a2:e185:e446:903a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7DKsVT06373; Wed, 14 Aug 2002 05:54:31 +0900 (JST) Date: Wed, 14 Aug 2002 05:54:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 13 Aug 2002 12:54:19 -0700 (PDT), >>>>> Julian Elischer said: >> > I'm looking at the -STABLE sources for a bug we're having at work with >> > a high capacity server that uses UDP. >> >> > The bug is that when we run out of mbufs in udp_output() we do NOT >> > disconnect the socket that caused the error. All error cases goto release: >> > which >> > is after the in_pcbdisconnect() call. Is this intentional? >> >> I don't think so. The socket should be disconnected before returning >> the error. > Why? > dropping a udp packet due to lack of local resources shouldn't affect the > state of the socket.. just as having a router drop the packet shouldn't > affect it.. I don't understnad the question I guess. I guess I was not clear. I read the original message to mean temporarily connected UDP sockets. With the current code (I'm looking at the rev. 1.64.2.15 of udp_usrreq.c) once the error happens the socket will be locked as connected, and will not be able to receive from other sources than the foreign address (while it should be, because it is not connected by the application). The fix would be like this (btw: we may want to combine the disconnect part to avoid code duplication): --- udp_usrreq.c.orig Tue Aug 13 13:49:50 2002 +++ udp_usrreq.c Tue Aug 13 13:52:34 2002 @@ -704,9 +704,7 @@ M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT); if (m == 0) { error = ENOBUFS; - if (addr) - splx(s); - goto release; + goto disconnect; } /* @@ -741,7 +739,7 @@ #ifdef IPSEC if (ipsec_setsocket(m, inp->inp_socket) != 0) { error = ENOBUFS; - goto release; + goto disconnect; } #endif /*IPSEC*/ error = ip_output(m, inp->inp_options, &inp->inp_route, @@ -754,6 +752,13 @@ splx(s); } return (error); + +disconnect: + if (addr) { + in_pcbdisconnect(inp); + inp->inp_laddr = laddr; /* XXX rehash? */ + splx(s); + } release: m_freem(m); JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message