On Thu, 20 Apr 2017 21:41:28 +0200 Marko Zec <z...@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] > > On Thu, 20 Apr 2017 21:24:33 +0200 > <peter.b...@bsd4all.org> wrote: > > > It doesn’t 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 > > 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 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
