From owner-freebsd-current@freebsd.org Fri Oct 9 07:38:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AF159D1316 for ; Fri, 9 Oct 2015 07:38:38 +0000 (UTC) (envelope-from white_knight@2ch.net) Received: from mail.nttec.com (mail.nttec.com [207.29.234.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B19C1F6 for ; Fri, 9 Oct 2015 07:38:37 +0000 (UTC) (envelope-from white_knight@2ch.net) Received: from mail.nttec.com (localhost [127.0.0.1]) by mail.nttec.com (Postfix) with ESMTPA id F0C3614130E for ; Fri, 9 Oct 2015 00:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 09 Oct 2015 15:23:31 +0800 From: White Knight To: freebsd-current@freebsd.org Subject: The kern.ipc.somaxconn limit revisited. Organization: 2ch.net Message-ID: X-Sender: white_knight@2ch.net User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 07:38:38 -0000 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.