Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2017 21:50:40 +0200
From:      Marko Zec <zec@fer.hr>
To:        <peter.blok@bsd4all.org>
Cc:        Kristof Provost <kristof@sigsegv.be>, <freebsd-net@freebsd.org>
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> <ACA8734E-88DF-4E7F-BB54-00D393ED7EA6@sigsegv.be> <C662C1B6-BCB7-4B92-9512-9E5B085B0AF8@bsd4all.org> <20170420214128.29379fdb@x23>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Apr 2017 21:41:28 +0200
Marko Zec <zec@fer.hr> 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
> <peter.blok@bsd4all.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170420215040.4ee94610>