Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote:
> Hi,
>
> Here's what I have thus far. Please ignore the device_printf() change.
>
> This works for me, both for hotplug cardbus wireless devices as well
> as (inadvertently!) a USB bluetooth device.
>
> What do you think?
It looks that you've hit the right spot to set curvnet context in
device_probe_and_attach().
Could you try out a slightly revised verstion (attached) - this one also
removes now redundant curvnet setting from linker routines (kldload /
kldunload), and adds a few extra bits which might be necessary for a
broader range of drivers to work.
Note that I haven't tested this myself as I don't have a -CURRENT machine
ATM, but a similar patch for 8.3 apparently works fine, though I don't have
hotplugabble network cards to play with (neither cardbus nor USB)...
Cheers,
Marko
Index: sys/kern/subr_bus.c
===
--- sys/kern/subr_bus.c (revision 243091)
+++ sys/kern/subr_bus.c (working copy)
@@ -53,6 +53,8 @@
#include
#include
+#include
+
#include
#include
@@ -2735,7 +2737,11 @@
return (0);
else if (error != 0)
return (error);
- return (device_attach(dev));
+
+ CURVNET_SET_QUIET(vnet0);
+ error = device_attach(dev);
+ CURVNET_RESTORE();
+ return (error);
}
/**
Index: sys/kern/kern_linker.c
===
--- sys/kern/kern_linker.c (revision 243091)
+++ sys/kern/kern_linker.c (working copy)
@@ -53,8 +53,6 @@
#include
#include
-#include
-
#include
#include "linker_if.h"
@@ -1019,12 +1017,6 @@
return (error);
/*
- * It is possible that kldloaded module will attach a new ifnet,
- * so vnet context must be set when this ocurs.
- */
- CURVNET_SET(TD_TO_VNET(td));
-
- /*
* If file does not contain a qualified name or any dot in it
* (kldname.ko, or kldname.ver.ko) treat it as an interface
* name.
@@ -1041,7 +1033,7 @@
error = linker_load_module(kldname, modname, NULL, NULL, &lf);
if (error) {
KLD_UNLOCK();
- goto done;
+ return (error);
}
lf->userrefs++;
if (fileid != NULL)
@@ -1055,9 +1047,6 @@
#else
KLD_UNLOCK();
#endif
-
-done:
- CURVNET_RESTORE();
return (error);
}
@@ -1095,7 +1084,6 @@
if ((error = priv_check(td, PRIV_KLD_UNLOAD)) != 0)
return (error);
- CURVNET_SET(TD_TO_VNET(td));
KLD_LOCK();
lf = linker_find_file_by_id(fileid);
if (lf) {
@@ -1137,7 +1125,6 @@
#else
KLD_UNLOCK();
#endif
- CURVNET_RESTORE();
return (error);
}
Index: sys/netgraph/bluetooth/socket/ng_btsocket.c
===
--- sys/netgraph/bluetooth/socket/ng_btsocket.c (revision 243091)
+++ sys/netgraph/bluetooth/socket/ng_btsocket.c (working copy)
@@ -46,6 +46,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -285,4 +287,4 @@
return (error);
} /* ng_btsocket_modevent */
-DOMAIN_SET(ng_btsocket_);
+VNET_DOMAIN_SET(ng_btsocket_);
Index: sys/net/if.c
===
--- sys/net/if.c (revision 243091)
+++ sys/net/if.c (working copy)
@@ -504,6 +504,7 @@
ifp->if_flags |= IFF_DYING; /* XXX: Locking */
+ CURVNET_SET_QUIET(ifp->if_vnet);
IFNET_WLOCK();
KASSERT(ifp == ifnet_byindex_locked(ifp->if_index),
("%s: freeing unallocated ifnet", ifp->if_xname));
@@ -511,9 +512,9 @@
ifindex_free_locked(ifp->if_index);
IFNET_WUNLOCK();
- if (!refcount_release(&ifp->if_refcount))
- return;
- if_free_internal(ifp);
+ if (refcount_release(&ifp->if_refcount))
+ if_free_internal(ifp);
+ CURVNET_RESTORE();
}
/*
@@ -793,7 +794,9 @@
if_detach(struct ifnet *ifp)
{
+ CURVNET_SET_QUIET(ifp->if_vnet);
if_detach_internal(ifp, 0);
+ CURVNET_RESTORE();
}
static void
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
Hans brings up a very good point for USB - they split if_alloc and if_attach across two different threads. So this works for non-USB devices, but not for USB devices. 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? Adrian On 15 November 2012 09:36, Marko Zec wrote: > On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote: >> Hi, >> >> Here's what I have thus far. Please ignore the device_printf() change. >> >> This works for me, both for hotplug cardbus wireless devices as well >> as (inadvertently!) a USB bluetooth device. >> >> What do you think? > > It looks that you've hit the right spot to set curvnet context in > device_probe_and_attach(). > > Could you try out a slightly revised verstion (attached) - this one also > removes now redundant curvnet setting from linker routines (kldload / > kldunload), and adds a few extra bits which might be necessary for a > broader range of drivers to work. > > Note that I haven't tested this myself as I don't have a -CURRENT machine > ATM, but a similar patch for 8.3 apparently works fine, though I don't have > hotplugabble network cards to play with (neither cardbus nor USB)... > > Cheers, > > Marko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
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. > > So this works for non-USB devices, but not for USB devices. > > 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? --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
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-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: "Weighted round robin" for LAGG - anyhow?
Hi, > you can use mpd (or ppp) in multilink mode to encapsulate your outgoing links > via two different tcp paths to you other server where you can undo it.. I didn't know about mpd (or ppp multilink). Actually, it seems to be exactly what I need. Better than lagg, for this situation. The problem is: I never dealt with PPP links (not more than "connect" on my modem), so I'm studying that for now. I've been able to set up a dual link pptp connection (still can't figure out how to create just a TCP or UDP flow, but I hope I'll sort it out). I'm going to do some tests. Thank you for your suggestion! Stefano ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
NFS over SCTP -- is anyone likely to implement this?
I'm working on (of all things) a Puppet module to configure NFS servers, and I'm wondering if anyone expects to implement NFS over SCTP on FreeBSD. -GAWollman ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
