From owner-freebsd-current@freebsd.org Sun Aug 9 10:36:41 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 5FD99998A9A for ; Sun, 9 Aug 2015 10:36:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7A99A0; Sun, 9 Aug 2015 10:36:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.15.2/8.15.2) with ESMTPS id t79AaZuL071365 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Aug 2015 13:36:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.15.2/8.15.2/Submit) id t79AaZW2071364; Sun, 9 Aug 2015 13:36:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 9 Aug 2015 13:36:35 +0300 From: Gleb Smirnoff To: Kristof Provost Cc: Patrick Kelsey , freebsd-current@freebsd.org Subject: Re: sysctl -a panic on VIMAGE kernels Message-ID: <20150809103635.GA889@glebius.int.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sun, 09 Aug 2015 10:36:41 -0000 On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: K> Hi, K> K> I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’. K> K> Relevant backtrace bits: K> #8 0xffffffff80e7dd28 in trap (frame=0xfffffe01f16b26a0) K> at /usr/src/sys/amd64/amd64/trap.c:426 K> #9 0xffffffff80e5e6a2 in calltrap () K> at /usr/src/sys/amd64/amd64/exception.S:235 K> #10 0xffffffff80cea67d in uma_zone_get_cur (zone=0x0) K> at /usr/src/sys/vm/uma_core.c:3006 K> #11 0xffffffff80cec029 in sysctl_handle_uma_zone_cur ( K> oidp=0xffffffff818a7c90, arg1=0xfffffe00010c0438, arg2=0, K> req=0xfffffe01f16b2868) at /usr/src/sys/vm/uma_core.c:3580 K> #12 0xffffffff80a28614 in sysctl_root_handler_locked (oid=0xffffffff818a7c90, K> arg1=0xfffffe00010c0438, arg2=0, req=0xfffffe01f16b2868) K> at /usr/src/sys/kern/kern_sysctl.c:183 K> #13 0xffffffff80a27d70 in sysctl_root (arg1=, K> arg2=) at /usr/src/sys/kern/kern_sysctl.c:1694 K> #14 0xffffffff80a28372 in userland_sysctl (td=0x0, name=0xfffffe01f16b2930, K> namelen=, old=, K> oldlenp=, inkernel=, K> new=, newlen=, K> retval=, flags=0) K> at /usr/src/sys/kern/kern_sysctl.c:1798 K> #15 0xffffffff80a28144 in sys___sysctl (td=0xfffff8000b1e49a0, K> uap=0xfffffe01f16b2a40) at /usr/src/sys/kern/kern_sysctl.c:1724 K> K> In essence, what happens is that we end up in sysctl_handle_uma_zone_cur() and arg1 is a pointer to NULL, K> so we call uma_zone_get_cur(zone); with zone == NULL. K> K> There’s been a bit of churn around tcp_reass_zone, and I think the latest version is wrong. K> It marks the sysctl as CTLFLAG_VNET, but the exposed variable is not VNET_DEFINE(). K> K> The following fixes it for me: K> K> diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c K> index 77d8940..3913ef3 100644 K> --- a/sys/netinet/tcp_reass.c K> +++ b/sys/netinet/tcp_reass.c K> @@ -84,7 +84,7 @@ SYSCTL_INT(_net_inet_tcp_reass, OID_AUTO, maxsegments, CTLFLAG_RDTUN, K> "Global maximum number of TCP Segments in Reassembly Queue"); K> K> static uma_zone_t tcp_reass_zone; K> -SYSCTL_UMA_CUR(_net_inet_tcp_reass, OID_AUTO, cursegments, CTLFLAG_VNET, K> +SYSCTL_UMA_CUR(_net_inet_tcp_reass, OID_AUTO, cursegments, 0, K> &tcp_reass_zone, K> "Global number of TCP Segments currently in Reassembly Queue”); Right, if a variable isn't virtualized, the CTLFLAG_VNET must be removed. Patrick, how is your progress wuth improved reassembly? -- Totus tuus, Glebius.