Description of problem: I was doing experiments with some crypto filesystem modules, and thought I'd clean up. So I did "lsmod | gawk '{print $1}' | tail +1 | xargs -n1 rmmod", and my ssh session froze. It turns out that eth0 and eth1 (an e100 and a 3c59x card respectively) had a use-count of 0 as shown by lsmod. The kernel says "The use-count is zero? Sure I'll let you remove those modules." This does bad things to my network connections. "Gee Wilbur, you think so???" Version-Release number of selected component (if applicable): Linux kernel 2.6.8-1.541, Standard Linux kernel 2.6.8.1 How reproducible: Every time Steps to Reproduce: 1.ifup eth0 2.rmmod e100 3.networking goes away Actual results: It lets you remove the e100 (or 3c59x, whichever) kernel module. Expected results: It should not let you remove them, as they are in use. Additional info: This is present in the stock 2.6.8.1 kernel too.... Note: I'm hoping that the dependency/use-count system gets fixed, rather than have someone tell me "don't do that". Yes, I know "If it hurts when you do that, don't do that". I'm just saying that this bug is a symptom of a deeper problem.
I believe the rationale for this is that calculating use counts for network traffic would be pretty expensive (and have a performance hit), and instead everything is just expected to cope with the NIC going away. Early 2.6.x tried to do this, and what happened was that network drivers just couldn't easily be upgraded on the fly since something was always using them. I think of this as a feature, I can rmmod <nicdriver>; insmod <newversionofnicdriver>; ifup eth0 and my connections continue working just fine. Anyway, I'd say this is either UPSTREAM or NOTABUG, but not closing this as either :-)
indeed, this is defined upstream behaviour. If you'd like to see it change, ask upstream.