Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Oct 2012 21:36:12 +0200
From:      Marko Zec <zec@fer.hr>
To:        <freebsd-net@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Adrian Chadd <adrian@freebsd.org>
Subject:   Re: VIMAGE crashes on 9.x with hotplug net80211 devices
Message-ID:  <201210212136.12788.zec@fer.hr>
In-Reply-To: <CAJ-VmomchJZ7GUKrAjmmyBXDw-6H6O5fAxT_tfAFfhU=HknG1g@mail.gmail.com>
References:  <CAJ-VmomchJZ7GUKrAjmmyBXDw-6H6O5fAxT_tfAFfhU=HknG1g@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 21 October 2012 21:04:41 Adrian Chadd wrote:
> Hi all,
>
> I have some crashes in the VIMAGE code on releng_9. Specifically, when
> I enable VIMAGE and then hotplug some cardbus ath(4) NICs.
>
> The panics are dereferencing the V_ ifindex and related fields.
>
> If I start adding CURVNET_SET(vnet0) and CURVNET_RESTORE() around the
> ifnet calls (attach, detach) then things stop panicing - however,
> things are slightly more complicated than that.
>
> Since it's possible that the cloned interfaces (and maybe the parent
> interface?) are placed into other VNETs, I have to make sure that the
> right vnet context is switched to before I free interfaces.
>
> So, may I please have some help by some VIMAGE-cluey people to sort
> out how to _properly_ get VIMAGE up on net80211? I'd like to fix this
> in -HEAD and -9 so people are able to use VIMAGEs for hostapd
> interfaces (and so I can abuse it for lots of local testing on a
> single laptop.)

The right approach would be to do a single CURVNET_SET(vnet0) / 
CURVNET_RESTORE() somewhere near the root of the call graph being triggered 
by the hotplug attach event.  Not having any hotpluggable hardware at hand 
I cannot be more specific where that place could be...

But most certainly doing CURVNET_SET(vnet0) on detach events would be wrong: 
since ifnets may be assignet to non-default vnets, 
CURVNET_SET(ifp->if_vnet) should be more appropriate there.

Another thing that may help could be turning on options VNET_DEBUG when, as 
that should reveal excessive (and probably redundant) CURVNET_SET() 
recursions.

Hope this helps,

Marko



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