From owner-freebsd-current@freebsd.org Mon Apr 10 14:36:37 2017 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 C7D5FD37204 for ; Mon, 10 Apr 2017 14:36:37 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76BFA7C1 for ; Mon, 10 Apr 2017 14:36:36 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.133] (helo=smtp9.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1cxaAS-00086g-TZ; Mon, 10 Apr 2017 16:19:44 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp9.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1cxaAS-0003NN-Pm; Mon, 10 Apr 2017 16:19:44 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 27E117294; Mon, 10 Apr 2017 16:19:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkUrj3ENUN_j; Mon, 10 Apr 2017 16:19:38 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 087A2728A; Mon, 10 Apr 2017 16:19:37 +0200 (CEST) From: peter.blok@bsd4all.org Message-Id: <75BD8407-83AC-4383-912A-70083CED3FFD@bsd4all.org> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: VNET branch destiny Date: Mon, 10 Apr 2017 16:19:37 +0200 In-Reply-To: <58EB8D98.5050904@gmail.com> Cc: Pavel Timofeev , "Bjoern A. Zeeb" , freebsd-current To: Ernie Luzar References: <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> <24B3E322-5B92-470D-A1D6-10DF8EF79490@bsd4all.org> <58EB8D98.5050904@gmail.com> X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=DaNnkrlW c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=AzvcPWV-tVgA:10 a=pGLkceISAAAA:8 a=6Q3WNqvRAAAA:8 a=6I5d2MoRAAAA:8 a=EEZ-tilfT3c-UgNY3FoA:9 a=IG4rVTXlw-NOpdIq:21 a=dffPz0lcM9dU9V5V:21 a=QEXdDO2ut3YA:10 a=CTX6184NhUg2i1LZ3OMA:9 a=jot15N5koVxdeT_G:21 a=Og90m685kHM33Zxz:21 a=8LL_voLXoUa5cjVQ:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=I8PBwKCn76L9oNdl0isp:22 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Mon, 10 Apr 2017 14:36:37 -0000 Well, in my case it panic=E2=80=99ed on 11-stable. I=E2=80=99m only = using pf on the host, not in the jail. I=E2=80=99m using Devin Teske=E2=80= =99s jng to create a netgraph bridge. It is my intention to use the = netgrpah bridge with bhyve as well. The panic (one-time) happened in pfioctl when I refreshed the rules. I = suspect the problem is related to the following message when I stop the = jail. kernel: Freed UMA keg (pf table entries) was not empty (32 items). Lost = -57 pages of memory. Current does not display the UMA message. I=E2=80=99m still narrowing = down what happens with the pf table entries. My suspicion is that the = netgraph bridge which creates a ng_ether device which is handed over to = the jail vnet, is causing this. The panic happened on LIST_REMOVE in keg_fetch_slab static uma_slab_t keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags) { uma_slab_t slab; int reserve; mtx_assert(&keg->uk_lock, MA_OWNED); slab =3D NULL; reserve =3D 0; if ((flags & M_USE_RESERVE) =3D=3D 0) reserve =3D keg->uk_reserve; for (;;) { /* * Find a slab with some space. Prefer slabs that are = partially * used over those that are totally full. This helps to = reduce * fragmentation. */ if (keg->uk_free > reserve) { if (!LIST_EMPTY(&keg->uk_part_slab)) { slab =3D LIST_FIRST(&keg->uk_part_slab); } else { slab =3D LIST_FIRST(&keg->uk_free_slab); LIST_REMOVE(slab, us_link); LIST_INSERT_HEAD(&keg->uk_part_slab, = slab, us_link); } MPASS(slab->us_keg =3D=3D keg); return (slab); } KDB: stack backtrace: #0 0xffffffff805df0e7 at kdb_backtrace+0x67 #1 0xffffffff8059d176 at vpanic+0x186 #2 0xffffffff8059cfe3 at panic+0x43 #3 0xffffffff808ebaa2 at trap_fatal+0x322 #4 0xffffffff808ebaf9 at trap_pfault+0x49 #5 0xffffffff808eb336 at trap+0x286 #6 0xffffffff808d1441 at calltrap+0x8 #7 0xffffffff808a871e at zone_fetch_slab+0x6e #8 0xffffffff808a87cd at zone_import+0x4d #9 0xffffffff808a4fc9 at uma_zalloc_arg+0x529 #10 0xffffffff80803214 at pfr_ina_define+0x584 #11 0xffffffff807f0734 at pfioctl+0x3364 #12 0xffffffff80469288 at devfs_ioctl_f+0x128 #13 0xffffffff805fa925 at kern_ioctl+0x255 #14 0xffffffff805fa65f at sys_ioctl+0x16f #15 0xffffffff808ec604 at amd64_syscall+0x6c4 #16 0xffffffff808d172b at Xfast_syscall+0xfb The panic is so far not reproducible. > On 10 Apr 2017, at 15:50, Ernie Luzar wrote: >=20 > peter.blok@bsd4all.org wrote: >> There have been issues with pf if I recall correctly. I currently = have issues with stable, pf and vnet. There is an issue with pf table = entries when an interface is moved to a different vnet. >> Does anyone no if there is a specific fix for this that hasn=E2=80=99t = been ported to stable? I haven=E2=80=99t had the time to test this on = current. >> Peter >=20 > PF was fixed in 11.0 to not panic when run on a host that has vimage = compiled into the kernel. On 11.0 you can configure pf to run in a vnet = jail but it really does not enforce any firewall rules because pf needs = access to the kernel which jail(8) is blocking by design. As far as I = know this is a show shopper that can not be fixed without a pf rewrite = changing the way it works internally. >=20 > This PR gives all the details > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212013 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"