Yeah, you are right. To keep the pf code as unchanged as possible, it is sometimes unclear whether something is virtualised or not.
The SLIST_HEAD and RB_HEAD in pfvar.h need virtualisation as well. > On 20 Apr 2017, at 21:41, Marko Zec <z...@fer.hr> wrote: > > On Thu, 20 Apr 2017 21:24:33 +0200 > <peter.b...@bsd4all.org <mailto: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. > > Marko > >> >> >>> On 20 Apr 2017, at 15:32, Kristof Provost <kris...@sigsegv.be> >>> wrote: >>> >>> On 20 Apr 2017, at 15:28, Marko Zec wrote: >>>> Right. But pfi_attach_group_event() and the other handlers cited >>>> above _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding >>>> the proper vnet choice from the caller. >>>> >>> Yes, that does look wrong. >>> I should have looked a bit further. >>> >>>> Therefore the proper fix should be as simple as removing >>>> CURVNET_SET() / CURVNET_RESTORE() macro pairs from the cited >>>> handlers. >>> Hopefully, yes. I’ve still got some other pf/vnet issues on my todo >>> list, but I’ve now added this too. It might actually explain some >>> other bug report I’ve seen (but not looked at in any depth). >>> >>> Regards, >>> Kristof >>> _______________________________________________ >>> 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" _______________________________________________ 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"
