vale and netmap module questions

[Vincenzo Maffione]

Hi Marko,
  Thanks a lot for identifying the problem.
If I understand correctly, simply adding -D VIMAGE here
https://github.com/luigirizzo/netmap/blob/master/sys/modules/netmap/Makefile#L11
would at least mitigate the issue.
If you think I'm right I'll just add it.

Thanks,
  Vincenzo

Il giorno mer 5 set 2018 alle ore 10:44 Marko Zec <zec at fer.hr> ha scritto:

> On Tue, 4 Sep 2018 20:18:29 +0200
> Vincenzo Maffione <v.maffione at gmail.com> wrote:
>
> > Hi,
> >   I don't think the panic depends on the architecture. Also, it does
> > not depend on using emulated mode or not.
> > We have seen this happening on x86_64 on FreeBSD 12 head.
> >
> > As John-Mark says, kdloading netmap.ko is not enough. You need to
> > open a netmap port corresponding
> > to any network interface, e.g.
> >  # pkt-gen -i eth0
> > because this will trigger ifunit_ref() in the kernel (netmap tries to
> > grab the interface called "eth0").
> > The ifunit_ref() panics and we still need to figure out why.
>
> After more carefully rereading jmg's original report, on amd64 I
> reproduced exactly the same panic he reported on arm64, the summary
> follows:
>
> - the problem can be observed as VNET related, and can be triggered only
> on kernels built with "options VIMAGE" but without "device netmap".
>
> - netmap.ko built using make buildkernel works fine.
>
> - netmap.ko built separately (cd sys/modules/netmap; make) panics on a
>   first reference to vale interface, such as "tcpdump -ni vale1:a"
>
> - the problem is that the separately built module is compiled without
>   "options VIMAGE", and as such does not set curvnet prior to calling
>   into network stack functions, therefore we have a null pointer
>   dereference in ifunit_ref() and voila...
>
> - hence, there's nothing to fix in the netmap code, and there's nothing
>   to fix in the network stack either related to this particular problem,
>   but rather we need a general mechanism which would prevent kldloading
>   non-VNETized .ko modules into a VNETized kernel.  I have no idea how
>   to approach this, besides adding bz@ to the cc: list, perhaps he
>   could chime in with some thoughts?
>
> Cheers,
>
> Marko
>


-- 
Vincenzo