Re: The kern.ipc.somaxconn limit revisited.

I think it's worth upping to an int type, so we can eventually up it to > 64k.

Please do submit diffs for revie.w :)


-a


On 9 October 2015 at 00:23, White Knight <white_knight_at_2ch.net> wrote:
> 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.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"