> - We have been getting deadlocks at hotplug time because
> call_usermodehelper is synchronous: it returns control after the
> usermode application has exited. But in some places (esp.
> [un]register_netdevice) this happens with a lock held (rtnl_lock).
> This cause `ifconfig' to get stuck.
The /sbin/hotplug script I sent around last week avoids this by doing
its work in the background.
I see the underlying problem here as being that network hotplug hooks
are called at the wrong time ... because they are piggybacking onto
existing APIs, which weren't designed for hotplug support. Different
aspects of that root cause were all over your list of problems (seeming
to trigger all the nastiest ones :-).
To my way of thought (I don't claim expertise in Linux networking!)
the _clean_ fix here is accept that the network driver API needs an
update for hotplugging. Not a big one, I suspect. Likely we can
start with a "ready to open this device!" call, which hotplug-ready
network drivers call at the end of their PCI or USB probe routines.
We've needed such changes in both PCI and USB driver APIs ... suggesting
that such changes are to be expected as new subsystems start to learn
how to autoconfigure themselves.
> - Add a check for an empty executable path string in
> call_usermodehelper. (This check can probably be removed from the
> USB code now?)
Sure.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 15 2000 - 21:00:21 EST