From owner-freebsd-net Tue Jan 14 2:52:34 2003 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 DDB6037B401; Tue, 14 Jan 2003 02:52:32 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6930C43F13; Tue, 14 Jan 2003 02:52:32 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0016.cvx40-bradley.dialup.earthlink.net ([216.244.42.16] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YOgA-0004H3-00; Tue, 14 Jan 2003 02:52:23 -0800 Message-ID: <3E23EB97.694EC9BB@mindspring.com> Date: Tue, 14 Jan 2003 02:51:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Blapp Cc: Thomas Moestl , current@freebsd.org, net@freebsd.org Subject: Re: PANIC in tcp_syncache.c sonewconn() line 562 References: <20030113173957.T73725@levais.imp.ch> <20030113215318.GA278@crow.dom2ip.de> <20030114100620.W76016@levais.imp.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b69f0fd50f242a60a260b1b1df9a76542601a10902912494350badd9bab72f9c350badd9bab72f9c 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 Martin Blapp wrote: > Can you commit this ? The fix looks appropriate, but the manpage should > also be changed to reflect the change. > > ERRORS > Listen() will fail if: > > [EBADF] The argument s is not a valid descriptor. > [ENOTSOCK] The argument s is not a socket. > [EOPNOTSUPP] The socket is not of a type that > supports the operation listen(). > [EINVAL] Listen() has been already called on the socket. > > Any objections from others ? It seems to me that calling listen() on a socket to change the listen queue depth is a reasonable thing to do; this is true before it's bound, after it's bound, before listen() has been called on it, and after listen() has been called on it once (or more). Am I missing something here? Is there a good technical reason to not permit an application to change the listen queue depth? Or is there some way that an application can do this, using a call other than listen()? That it causes a panic when the SYN cache is enabled isn't really a technical reason, it's a circumstantial reason. I can think of a lot of programs that might be based on FreeBSD, which would have a CLI that would let you change the wait queue (e.g. a Layer 7 load balancer, or an application proxy), where closing and reopening it -- and losing the pending connections which have performed the SYN/SYN-ACK/ACK, but have not had accept called on them yt), where it would not just be a legitimate use, it would be a required feature. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message