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>