From owner-svn-src-all@FreeBSD.ORG Mon Mar 16 17:56:11 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E43EDCBD; Mon, 16 Mar 2015 17:56:10 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i53.relay.mailchannels.net [184.154.112.227]) by mx1.freebsd.org (Postfix) with ESMTP id 876BF9B6; Mon, 16 Mar 2015 17:56:06 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id A81931D06A0; Mon, 16 Mar 2015 17:48:00 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org ([TEMPUNAVAIL]. [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 16 Mar 2015 17:48:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426528081830:1738845448 X-MC-Ingress-Time: 1426528081830 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YXZ7J-0005kF-GJ; Mon, 16 Mar 2015 17:47:53 +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 t2GHlprk023640; Mon, 16 Mar 2015 11:47:51 -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: U2FsdGVkX1+G/oyPHS569iDHcrRbTXxw Message-ID: <1426528071.95554.2.camel@freebsd.org> Subject: Re: svn commit: r279993 - in head/sys: dev/cxgb dev/cxgbe kern vm From: Ian Lepore To: Konstantin Belousov Date: Mon, 16 Mar 2015 11:47:51 -0600 In-Reply-To: <20150315215348.GV2379@kib.kiev.ua> References: <201503141708.t2EH8TdR074383@svn.freebsd.org> <20150315215348.GV2379@kib.kiev.ua> 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:56:11 -0000 On Sun, 2015-03-15 at 23:53 +0200, Konstantin Belousov wrote: > On Sat, Mar 14, 2015 at 05:08:29PM +0000, Ian Lepore wrote: > > Author: ian > > Date: Sat Mar 14 17:08:28 2015 > > New Revision: 279993 > > URL: https://svnweb.freebsd.org/changeset/base/279993 > > > > Log: > > Set the SBUF_INCLUDENUL flag in sbuf_new_for_sysctl() so that sysctl > > strings returned to userland include the nulterm byte. > > > > Some uses of sbuf_new_for_sysctl() write binary data rather than strings; > > clear the SBUF_INCLUDENUL flag after calling sbuf_new_for_sysctl() in > > those cases. (Note that the sbuf code still automatically adds a nulterm > > byte in sbuf_finish(), but since it's not included in the length it won't > > get copied to userland along with the binary data.) > > > > Remove explicit adding of a nulterm byte in a couple places now that it > > gets done automatically by the sbuf drain code. > > > > PR: 195668 > > I get the following panic on r280044: > > panic: wrote past end of sbuf (256 >= 256) > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8028db5b = db_trace_self_wrapper+0x2b/frame 0xfffffe022b6af5e0 > vpanic() at 0xffffffff80356ad9 = vpanic+0x189/frame 0xfffffe022b6af660 > kassert_panic() at 0xffffffff80356942 = kassert_panic+0x192/frame 0xfffffe022b6af6f0 > sbuf_delete() at 0xffffffff803a3cad = sbuf_delete+0xad/frame 0xfffffe022b6af710 > sysctl_kern_proc_args() at 0xffffffff80349b6d = sysctl_kern_proc_args+0x21d/frame 0xfffffe022b6af7a0 > sysctl_root_handler_locked() at 0xffffffff80364034 = sysctl_root_handler_locked+0x94/frame 0xfffffe022b6af7e0 > sysctl_root() at 0xffffffff80363878 = sysctl_root+0x188/frame 0xfffffe022b6af830 > userland_sysctl() at 0xffffffff80363e12 = userland_sysctl+0x192/frame 0xfffffe022b6af8d0 > sys___sysctl() at 0xffffffff80363c44 = sys___sysctl+0x74/frame 0xfffffe022b6af980 > amd64_syscall() at 0xffffffff8057e9be = amd64_syscall+0x2ae/frame 0xfffffe022b6afab0 > Xfast_syscall() at 0xffffffff8055d9bb = Xfast_syscall+0xfb/frame 0xfffffe022b6afab0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800f9db0a, rsp = 0x7fffffffe2c8, rbp = 0x7fffffffe300 --- This should now be fixed with r280149. I have no idea why I never hit this in testing even with the same commands that other people on irc said they were using to trigger it. Just lucky I guess. :) -- Ian