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 > 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"
