From owner-freebsd-net@freebsd.org Thu Apr 20 19:50:23 2017 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 D3FA2D47101 for ; Thu, 20 Apr 2017 19:50:23 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B23DCA9 for ; Thu, 20 Apr 2017 19:50:23 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.110.161) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 21:50:20 +0200 Date: Thu, 20 Apr 2017 21:50:40 +0200 From: Marko Zec To: CC: Kristof Provost , Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420215040.4ee94610@x23> In-Reply-To: <20170420214128.29379fdb@x23> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> <20170420214128.29379fdb@x23> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [31.147.110.161] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:50:23 -0000 On Thu, 20 Apr 2017 21:41:28 +0200 Marko Zec wrote: > [This sender failed our fraud detection checks and may not be who > they appear to be. Learn about spoofing at > http://aka.ms/LearnAboutSpoofing] >=20 > On Thu, 20 Apr 2017 21:24:33 +0200 > wrote: >=20 > > It doesn=E2=80=99t solve my problem, but below is the stack back trace = that > > leads to the problem that allocation doen for the default vnet are > > given back as part of the vnet destroy. > > > > #0 0xffffffff807ff275 at pfr_destroy_kentry+0x35 > > #1 0xffffffff807fe47c at pfr_remove_kentries+0x1fc > > #2 0xffffffff808053cd at pfr_setflags_ktable+0xcd > > #3 0xffffffff80802108 at pfr_clr_tables+0x248 > > #4 0xffffffff807ecd75 at vnet_pf_uninit+0x4a5 > > #5 0xffffffff806a9d2c at vnet_destroy+0x13c > > #6 0xffffffff8056cdcf at prison_deref+0x2af > > #7 0xffffffff805ee287 at taskqueue_run_locked+0x127 > > #8 0xffffffff805ef428 at taskqueue_thread_loop+0xc8 > > #9 0xffffffff80565505 at fork_exit+0x85 > > #10 0xffffffff808d245e at fork_trampoline+0xe =20 >=20 > Having absolutely no clue what the PF code does or is supposed to do, > I'd bet that V_irtualizing pfr_ktablehead, and probably pfr_nulltable > and pfr_ktable_cnt as well, would help here. pf_main_anchor looks suspicious, too, as it is never dereferenced via the VNET() accessor, so effectively it is still used as a single global variable. Marko