MFC VIMAGE fixes to 11-stable

[peter.blok at bsd4all.org]

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 <zec at fer.hr> wrote:
> 
> On Thu, 20 Apr 2017 21:24:33 +0200
> <peter.blok at bsd4all.org <mailto:peter.blok at 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 <kristof at 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 at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to
>>> "freebsd-net-unsubscribe at freebsd.org"