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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
