From owner-freebsd-net@freebsd.org Wed Nov 11 00:24:36 2015 Return-Path: Delivered-To: freebsd-net@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 2BDA7A2C741 for ; Wed, 11 Nov 2015 00:24:36 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 17E3C1A94; Wed, 11 Nov 2015 00:24:36 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from AlfredMacbookAir.local (unknown [IPv6:2601:645:8004:7515:1ccf:45dd:4d00:90ef]) by elvis.mu.org (Postfix) with ESMTPSA id B4430345A981; Tue, 10 Nov 2015 16:24:34 -0800 (PST) Subject: Re: kern.ipc.sockbuf limits: anyone mind if I commit this? To: freebsd-net@freebsd.org, Adrian Chadd References: From: Alfred Perlstein Organization: FreeBSD Message-ID: <56428AC2.6030600@freebsd.org> Date: Tue, 10 Nov 2015 16:24:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 00:24:36 -0000 On 11/10/15 3:13 PM, Adrian Chadd wrote: > hiya, > > there's a PR with a patch: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204438 > > https://github.com/sparrc/freebsd/commit/157f90c55d1d54d33f41c6f7517de1a9c5f5e229 > > Does anyone know why setting the limits isn't as simple as this patch? > > Does anyone mind if I just commit this? > Don't mind too heavily, however the old behavior is bad and confusing however at least it stops you, however the new behavior will be odd and incorrect without warning. More succinctly: Silently "accepting" but actually changing the value passed in seems wrong. It would seem the reason for the calculation is to actually limit the number of bytes of mbufs (not just data) to the max value? Is that true? Maybe it makes sense to export sb_max_adj via sysctl and allow setting of it instead? Having silent clipping seems worse than an error. -Alfred