Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Mar 2012 20:52:39 +0100
From:      Marko Zec <zec@fer.hr>
To:        freebsd-virtualization@freebsd.org
Cc:        Adrian Chadd <adrian.chadd@gmail.com>
Subject:   Re: VIMAGE + kldload wlan + kldload wtap panic
Message-ID:  <201203062052.39902.zec@fer.hr>
In-Reply-To: <CAJ-VmomY7ipsvok1pACjPU-Y933uTTiZ5-6EZG0B=Ofw226owg@mail.gmail.com>
References:  <CA%2BsBSo%2Bt=p0HLbyOH87DOJWWYn%2Be%2Bok7cwRiL1c1=gCw5=KTqg@mail.gmail.com> <201203061633.03446.zec@fer.hr> <CAJ-VmomY7ipsvok1pACjPU-Y933uTTiZ5-6EZG0B=Ofw226owg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 06 March 2012 19:01:11 Adrian Chadd wrote:
> Hi,
>
> What do we need to do to get VNET working in net80211 and the network
> drivers?

In principle one shouldn't have to touch anything in the network drivers.

In order for networking code to properly resolve virtualized state, curvnet=
=20
(which is a synonim for curthread->td_vnet) must be set to a proper context=
=20
when calling into networking code, and restored to previous value on=20
returned.  CURVNET_SET() and CURVNET_RESTORE() are macros which should be=20
used to do this.

As far as I know there are three ways for a function call to end up in the=
=20
networking code: A) system calls (socket related, or syctls); B) servicing=
=20
inbound packets; and C) timers / periodic tasks.

Cases A) and B) should be mostly covered in generic socket handlers and in=
=20
netisr dispatchers, except sysctls which need to access any state you may=20
have decided to virtualize - those should converted to use SYSCTL_VNET_*=20
macros.

Cases which fall into category C) are the ones which probably require most=
=20
attention and in certain cases may require certain amount of code=20
restructuring.  Handlers which are dispatched via timers are not bound to a=
ny=20
of the network stack instances, so in those you have to follow one of the t=
wo=20
possible strategies:

1) iterate over all existing VNETs and do your timer-driven stuff once in e=
ach=20
of those - in that case take a look at how VNET_LIST_RLOCK(),=20
VNET_ITERATOR_DECL() and VNET_FOREACH() family of macros are used elsewhere=
,=20
or

2) if the timer-driven event is bound to an object which is associated with=
 an=20
ifnet interface, you should explicitly set the curvnet context to match the=
=20
one the ifnet is associated with, using CURVNET_SET(ifp->if_vnet), as I=20
pointed out earlier in this thread.

Buiding a VNET_DEBUG kernel may help you a bit to find out the critical spo=
ts=20
when things go wrong, but don't expect miracles...

I think both Julian and Bjoern have already written pretty nice and extensi=
ve=20
documents covering those topics, but I would't know the current status or=20
whereabouts of those...

Hope this helps,

Marko



> Adrian
>
> On 6 March 2012 07:33, Marko Zec <zec@fer.hr> wrote:
> > On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote:
> >> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec <zec@fer.hr> wrote:
> >> > On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote:
> >> >> Hi,
> >> >>
> >> >> I am a very happy VIMAGE user. But lately I have been having proble=
ms
> >> >> using it, and its too complicated for me to dig in so I hope you can
> >> >> help me (and help Adrian too).
> >> >>
> >> >> I am using FreeBSD Current with a kernel config without wlan module
> >> >> and wireless devices =A0attach kernel config.
> >> >>
> >> >> uname -a shows:
> >> >> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar =A05
> >> >> 20:02:38 CET 2012 =A0 =A0
> >> >> root@acke:/usr/obj/usr/src/sys/VNET_without_wlan =A0amd64
> >> >>
> >> >> I run the following commands:
> >> >> cd /usr/sys/module/wlan
> >> >> make load
> >> >> cd /usr/sys/modules/wtap
> >> >> make load
> >> >>
> >> >> then:
> >> >> /usr/src/ools/tools/wtap/wtap/wtap c 0
> >> >> ifconfig wlan create wlandev wtap0 wlanmode mesh
> >> >> wlandebug -i wlan0 hwmp+mesh+output+input+inact
> >> >> ifconfig wlan0 meshid mymesh
> >> >> ifconfig wlan0 inet 192.168.2.1
> >> >>
> >> >> and freebsd panics with:
> >> >> Mon Mar =A05 21:17:46 CET 2012
> >> >> Mar =A05 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0
> >> >> Using visibility wtap plugin...
> >> >> Loaded wtap wireless simulator
> >> >> wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0:
> >> >> ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethern=
et
> >> >> address: 00:98:9a:98:96:97
> >> >> wlan0: ieee80211_start: ignore queue, in SCAN state
> >> >> wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2
> >> >> Kernel page fault with the following non-sleepable locks held:
> >> >> exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r =3D 0
> >> >> (0xffffff8002395018) locked @
> >> >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937
> >> >> KDB: stack backtrace:
> >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >> >> kdb_backtrace() at kdb_backtrace+0x37
> >> >> _witness_debugger() at _witness_debugger+0x2c
> >> >> witness_warn() at witness_warn+0x2c4
> >> >> trap() at trap+0x2fe
> >> >> calltrap() at calltrap+0x8
> >> >> --- trap 0xc, rip =3D 0xffffffff80885d0c, rsp =3D 0xffffff80003e9a0=
0, rbp
> >> >> =3D 0xffffff80003e9a20 ---
> >> >> rt_dispatch() at rt_dispatch+0x2c
> >> >> rt_ieee80211msg() at rt_ieee80211msg+0x7f
> >> >> scan_task() at scan_task+0x4cd
> >> >> taskqueue_run_locked() at taskqueue_run_locked+0x93
> >> >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3e
> >> >
> >> > It may be that scan_task() calls further down into the network stack
> >> > without setting curvnet first.
> >>
> >> I added CURVNET_SET(TD_TO_VNET(curthread))/CURVNET_RESTORE() in
> >> scan_task but it didnt help
> >
> > scan_task() is called from a taskqueue trampoline which doesn't have a
> > valid TD_TO_VNET(curthread) context, so what you attempted to do can't
> > work. =A0You need to set curvnet context to the one to which the network
> > interface (or a packet) you're working with belongs to. =A0Perhaps you
> > could use
> >
> > (struct ieee80211_scan_state *) ss->ss_vap->iv_ifp->if_curvnet
> >
> > in scan_task() to set curvnet, but having no clue on how the 80211 code
> > works, I might be wrong...
> >
> > And maybe you could consider rebuilding your kernel with options
> > VNET_DEBUG turned on - that should more verbosely point to the problem =
at
> > hand, while not introducing too big a performance penalty at runtime.
> >
> > Good luck,
> >
> > Marko
>
> _______________________________________________
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe@freebsd.org"





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