>Groan< The "unregister_netdevice" bug is back.
I haven't been able to do extensive testing, but I have
just encountered the message
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
again. Once it starts, it repeats ad infinitum, once per second.
The message starts spewing when I do a "cardctl eject"
on a Xircom CEM56 modem/ethernet card (driven by xirc2ps_cs.o, serial.o)
which was previously configured using DHCP with IPX enabled. The cardctl
eject never completes and the OS will not shut down completely; it hangs
at the point where it tries to de-configure network interfaces. Disabling
IPX cured the problem for me the next time I tried.
I am running 2.4.6-ac2, but the bug could have been reintroduced
a while back. I haven't been using Ethernet for a couple of
months.
Well, I'm no expert on the networking code, so I'll just suggest
some things that look odd to me. I'm looking in net/ipx/af_ipx.c,
tracing through ipxitf_create(). This function exits with dev->refcnt
incremented ... unless something goes wrong, in which case the function
exits through via a goto to "out_dev" which decrements the refcnt again.
Likewise, ipxitf_auto_create() increments the dev refcnt (by doing a
dev_hold(dev)) if all goes well. However when I look at ipxitf_delete(),
which I presume ought to undo what the *_create() functions do, I see
nothing that decrements the refcnt.
If this is where the bug lies then I would suggest that the functions
be documented to say that "this function exits with the refcnt incremented
if blah blah blah", etc.
As an aside, I notice that __dev_get_by_name() is called from ipxitf_delete().
A comment preceding __dev_get_by_name() in net/core/dev.c says that this
function should be called "under RTNL semaphore or @dev_base_lock", but
it is actually called under the ipx_interfaces_lock. Is this okay?
__dev_get_by_name() is also called from within ipxitf_ioctl(), seemingly
under no locks at all. Also okay?
Thomas Hood
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 21:00:13 EST