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 wrote:
>
> On Thu, 20 Apr 2017 21:24:33 +0200
> mailto:p
On Thu, 20 Apr 2017 21:41:28 +0200
Marko Zec 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
> wrote:
>
> > It doesn’t solve my problem, but below
On Thu, 20 Apr 2017 21:24:33 +0200
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 0x807ff275 at pfr_destroy_kentry+0x35
> #1 0x807fe
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 0x807ff275 at pfr_destroy_kentry+0x35
#1 0x807fe47c at pfr_remove_kentries+0x1fc
#2 0x808053cd
I’ll test this today.
> On 20 Apr 2017, at 15:32, Kristof Provost 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 call
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 p
On Thu, 20 Apr 2017 15:13:42 +0200
Kristof Provost wrote:
> On 20 Apr 2017, at 12:42, Marko Zec wrote:
> > The real culprit lies somewhere in PF code which operates on a wrong
> > vnet. Without a backtrace it's difficult to guess, but a quick read
> > reveals that
> >
> > pfi_initialize()
> >
>
On 20 Apr 2017, at 12:42, Marko Zec wrote:
The real culprit lies somewhere in PF code which operates on a wrong
vnet. Without a backtrace it's difficult to guess, but a quick read
reveals that
pfi_initialize()
is called from the default vnet context, and subsequently registers
interface eventh
Hi Marko,
Thanks for the pointer. It was not my intention to have this committed, but it
helped identify other problems. I have asked this before in -current, but got
no answer so I posted it here to get an answer.
If you look inside slab_free_item there is a KASSERT for just this, so that’s
w
On Wed, 19 Apr 2017 21:31:50 +0200
wrote:
...
> I also have a change in zone_release to fix another panic and leak in
> slab_free_item. The issue is that zone_release tries to release a keg
> that never belonged to the zone it is trying to release. With my
> limited knowledge, i think that should
10 matches
Mail list logo
