Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2017 15:28:53 +0200
From:      Marko Zec <zec@fer.hr>
To:        Kristof Provost <kristof@sigsegv.be>
Cc:        <peter.blok@bsd4all.org>, <freebsd-net@freebsd.org>
Subject:   Re: MFC VIMAGE fixes to 11-stable
Message-ID:  <20170420152853.019e5480@x23>
In-Reply-To: <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be>
References:  <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Apr 2017 15:13:42 +0200
Kristof Provost <kristof@sigsegv.be> 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()
> >
> > is called from the default vnet context, and subsequently registers
> > interface eventhandlers so that all interface attach, change and=20
> > detach
> > events will be always executed in the default vnet, regardless of
> > the real vnet where the interfaces bound to the events actually
> > reside. In
> > other words,
> >
> > pfi_attach_group_event()
> > pfi_change_group_event()
> > pfi_detach_group_event()
> >
> > will operate fine only in the default vnet, but will wreak havoc
> > otherwise.  Hence, those handlers should be fixed first.
> > =20
> I don=E2=80=99t think that=E2=80=99s right.
>=20
> The event handler doesn=E2=80=99t carry vnet information.  It=E2=80=99s j=
ust called=20
> in whatever vnet is active when it=E2=80=99s invoked.
> There's no CURVNET_SET() in the EVENTHANDLER_INVOKE() macro.
>=20
> That means that we end up in pf_attach_group_event() with CURVNET set
> to the relevant vnet, not to the default vnet.

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.

Therefore the proper fix should be as simple as removing CURVNET_SET() /
CURVNET_RESTORE() macro pairs from the cited handlers.

Marko


>=20
> There are certainly still issues with pf and vnets, but I don't think=20
> this is
> one.
>=20
> Regards,
> Kristof




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170420152853.019e5480>