From owner-freebsd-current@freebsd.org Fri Oct 9 18:47:33 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 F2C099D1E2A for ; Fri, 9 Oct 2015 18:47:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A1C10DA for ; Fri, 9 Oct 2015 18:47:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so41714980igc.1 for ; Fri, 09 Oct 2015 11:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HBKDY7ZE3K3+EvPMjtAUyyx04PyY83GqUN7PEsQww4s=; b=Uvdcg3fI1KnL5aVngZcUCPX3IGnWI9AKSCOtBoa7iIVnWps2xPfeDFEISpiCgdBgdY Pq4UyT/CFTBJ+iaQnkBbRcVCeOLkNGk1iihbj/JyLglgigKa+nWJeG2BW0o7A6c7dml9 7qOnJChIWtxBEn3hRTXHiQ+Z1O8/uLLJShBr/eq/+4vrNAqDQOxpnU9P64fKw1qhqJdU 7j+ppor/MmqYIPz30NFwxznZ420nftvfsjVMidXnFGS1Z2Z7V97tymETMx/gNPRyi1+R hi3rcl251BW1X0FRVlJQZ1X6f8M+kl8xR9xbk63kQG5iQ1623MMvZewAIqMKpe/wrone /j/A== MIME-Version: 1.0 X-Received: by 10.50.66.137 with SMTP id f9mr959538igt.22.1444416452151; Fri, 09 Oct 2015 11:47:32 -0700 (PDT) Received: by 10.36.46.15 with HTTP; Fri, 9 Oct 2015 11:47:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Oct 2015 11:47:32 -0700 Message-ID: Subject: Re: The kern.ipc.somaxconn limit revisited. From: Adrian Chadd To: White Knight Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 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 18:47:33 -0000 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 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"