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:


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@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to