Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2003 02:51:03 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Martin Blapp <mb@imp.ch>
Cc:        Thomas Moestl <tmoestl@gmx.net>, current@freebsd.org, net@freebsd.org
Subject:   Re: PANIC in tcp_syncache.c sonewconn() line 562
Message-ID:  <3E23EB97.694EC9BB@mindspring.com>
References:  <20030113173957.T73725@levais.imp.ch> <20030113215318.GA278@crow.dom2ip.de> <20030114100620.W76016@levais.imp.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
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-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E23EB97.694EC9BB>