The kern.ipc.somaxconn limit revisited.

Hi,

Back in 2012, raising the limit of kern.ipc.somaxcann was discussed (now 
properly called kern.ipc.acceptqueue) but nothing came of it.  The old 
discussion is here:

   
https://lists.freebsd.org/pipermail/freebsd-current/2012-January/030970.html

We are running into problems with the limit capped to 16 bits.  I am 
prepared to write the patch and do all the necessary testing.

A few things concern me.  The original patch(*) only changed the data 
types in usr/src/sys/sys/socketvar.h but neglected to update struct 
xsctp_inpcb in usr/src/sys/netinet/sctp_uio.h.

First, what are the consequences of changing struct xsctp_inpcb?  Is ok 
to change the type from u_short to u_int, or is it better to deprecate 
these fields and use the padding?  If I understand the code correctly, 
this is part of the userland ABI.

Second, if there is no arbitrary limit, this line in 
usr/src/sys/kern/uipc_socket.c can overflow.

   over = (head->so_qlen > 3 * head->so_qlimit / 2);

Should there be some arbitrary limit?

Third, the original patch changed the arbitrary limit from USHRT_MAX to 
UINT_MAX, but does that make any sense?  As written, it'll require the 
u_int to overflow for the test to ever be true.  Plus, the value is 
passed in as an int, so is it at all possible to give system call 
anything higher than INT_MAX?

Fourth, the snprintf() fields in usr/src/usr.bin/netstat/inet.c and 
usr/src/usr.bin/netstat/unix.c were not changed to account for larger 
than 16 bit numbers.  Is there really a need for a fixed length buffer 
to be formatted with snprintf() and then passed to printf()?

Fifth, is there any need to change the formatting string in 
usr/src/sys/kern/uipc_debug.c?

Sixth, in usr/src/sys/kern/uipc_socket.c, we have code like this, where 
optval is signed.

   optval = so->so_qlimit;

Does that mean the fields in struct socket are better off as signed than 
unsigned integers?


(*) 
https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031003.html


Thank you,

-- 
White Knight

I'm not from 2ch.net, I just work there.