Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2012 22:49:35 +0100
From:      Marko Zec <zec@fer.hr>
To:        Hans Petter Selasky <hselasky@c2i.net>, Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, freebsd-net@freebsd.org
Subject:   Re: VIMAGE crashes on 9.x with hotplug net80211 devices
Message-ID:  <201211152249.36161.zec@fer.hr>
In-Reply-To: <201211152032.06181.hselasky@c2i.net>
References:  <CAJ-VmomchJZ7GUKrAjmmyBXDw-6H6O5fAxT_tfAFfhU=HknG1g@mail.gmail.com> <CAJ-Vmo=WKJ6NxgGake4dqGV0jhOmpcsO2en=FC5U2zOkRqOn0A@mail.gmail.com> <201211152032.06181.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 15 November 2012 20:32:06 Hans Petter Selasky wrote:
> On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote:
> > Hans brings up a very good point for USB - they split if_alloc and
> > if_attach across two different threads.

Fine, so maybe one of the following options could work:

1) pass the vnet context embedded in some other already available struct 
when forwarding request from 1st to 2nd thread; or

2) if we can safely assume that device attach events can only occur in 
context of vnet0 (and I think we can), place a few CURVNET_SET(vnet0) 
macros wherever necessary in 2nd USB "attach" thread.

> > So this works for non-USB devices, but not for USB devices.

Could you post a sample backtrace for me to look at?

> > Hans, does each device implement its own workqueue for this kind of
> > delayed action, or is there some generic work queue that is doing this
> > work?
>
> Hi,
>
> I think a new thread is created for this stuff. It is inside the USB
> subsystem, but would consider this a big *hack* to add VNET specific
> stuff in there.
>
> Isn't it possible to have curvnet return "vnet0" when nothing else is
> set?

No!  This was discussed already at several ocassions, including earlier in 
this thread: with curvnet pointing by default to vnet0, it would be 
essentially impossible to detect, trace and debug leakages between vnets.

Marko



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