From owner-svn-src-head@FreeBSD.ORG Fri Mar 13 17:58:28 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3B1B1EB; Fri, 13 Mar 2015 17:58:28 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2D087C90; Fri, 13 Mar 2015 17:58:26 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 83129100680; Fri, 13 Mar 2015 17:58:18 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Fri, 13 Mar 2015 17:58:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426269498757:3396344620 X-MC-Ingress-Time: 1426269498757 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YWTqi-00071T-0T; Fri, 13 Mar 2015 17:58:16 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2DHvwuP016751; Fri, 13 Mar 2015 11:57:58 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18iIRWaFEO5DHw75k4FBabz Message-ID: <1426269478.19693.4.camel@freebsd.org> Subject: Re: svn commit: r279932 - head/sys/vm From: Ian Lepore To: John Baldwin Date: Fri, 13 Mar 2015 11:57:58 -0600 In-Reply-To: <3013452.2FfDYxpIKo@ralph.baldwin.cx> References: <201503121806.t2CI6VSU034853@svn.freebsd.org> <29142844.yUiOLJLpmU@ralph.baldwin.cx> <1426263267.91779.19.camel@freebsd.org> <3013452.2FfDYxpIKo@ralph.baldwin.cx> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Ryan Stone X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:58:28 -0000 On Fri, 2015-03-13 at 13:19 -0400, John Baldwin wrote: > On Friday, March 13, 2015 10:14:27 AM Ian Lepore wrote: > > On Fri, 2015-03-13 at 06:24 -0400, John Baldwin wrote: > > > On Thursday, March 12, 2015 05:24:51 PM Ian Lepore wrote: [...] > > > > In general I'm glad I got called away to an onsite meeting yesterday and > > didn't get far with these changes, because the more I think about it, > > the less satisfied I am with this expedient fix. The other fix I > > started on, where a new SBUF_COUNTNUL flag can be set to inform the > > sbuf_finish() code that you want the terminating nul counted in the data > > length just feels like a better fit for the overall "automaticness" of > > how the sbuf stuff works. > > Hmm, I actually think that it's a bug that the terminating nul isn't included > when draining. If we fixed that then I think that fixes most of these? > The places that explicitly use 'sysctl_handle_string()' with an sbuf > should probably just be using sbuf_len(sb) + 1' explicitly. (Another > option would be to have a sysctl_handle_sbuf() that was a wrapper around > sysctl_handle_string() that included the + 1 to hide that detail if there is > more than one.) > Some of the uses of sbuf for sysctl use sbuf_bcat() for dealing with binary structs, so we can't just assume that a nullterm should be added and included in the buffer length -- there needs to be some mechanism to say explicitly "this is an sbuf for a sysctl string" (and more generally "this is an sbuf for a string where I want the nul byte counted as part of the data" because that could be useful in non-sysctl contexts too, especially in userland). -- Ian