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