Date: Fri, 9 Oct 2015 11:47:32 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: White Knight <white_knight@2ch.net> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: The kern.ipc.somaxconn limit revisited. Message-ID: <CAJ-Vmo=MKz7s6VWBUpjOY16J4KVv-hj3oQX4JOEvP2Do%2B9A5UQ@mail.gmail.com> In-Reply-To: <ddc130c96b7b76ed22fb582b701a86f4@2ch.net> References: <ddc130c96b7b76ed22fb582b701a86f4@2ch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=MKz7s6VWBUpjOY16J4KVv-hj3oQX4JOEvP2Do%2B9A5UQ>