Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Apr 2017 16:19:37 +0200
From:      peter.blok@bsd4all.org
To:        Ernie Luzar <luzar722@gmail.com>
Cc:        Pavel Timofeev <timp87@gmail.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: VNET branch destiny
Message-ID:  <75BD8407-83AC-4383-912A-70083CED3FFD@bsd4all.org>
In-Reply-To: <58EB8D98.5050904@gmail.com>
References:  <CAAoTqfuAvZfoC-j8JFTvrpxqFMM5DjxyDXgMhMZLj3DO2pCYTw@mail.gmail.com> <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> <CAAoTqfvJ013NTQB75JeVCysfk-xk-hac-f73gXfvCt5bBo_QXA@mail.gmail.com> <CAAoTqfuQXvKAQNOwshY5mkt0dG7Z1jKC6Aae9TF4hum1aUrJsA@mail.gmail.com> <24B3E322-5B92-470D-A1D6-10DF8EF79490@bsd4all.org> <58EB8D98.5050904@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <luzar722@gmail.com> 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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75BD8407-83AC-4383-912A-70083CED3FFD>